Status of 440GP port

[andrew may]

On Tue, Apr 02, 2002 at 03:21:47PM -0700, Matt Porter wrote:
> On Tue, Apr 02, 2002 at 01:41:09PM -0800, andrew may wrote:
> > On Tue, Apr 02, 2002 at 02:18:45PM -0700, Matt Porter wrote:
> > >
> > > On Tue, Apr 02, 2002 at 11:46:12AM -0800, Eugene Surovegin wrote:
> > >
> > > I wouldn't say it has been underway for "quite some time".  4-5 working
> > > weeks is a short amount of development time for a new processor (at least
> > > for me). :)
> >
> > So are you useing your own repository to track your development? It sure
> > doesn't seem like the 2_4_devel tree is a development tree anymore. And
> > seeing how hard it has become to get changes into the "devel" tree also
> > suggests that the tree is not really a development tree.
>
> Hrm.  I've simply not checked in any files to my local _devel clone.
> Unlike other developers, I choose not to push in non-tested and/or
> non-working bits.  I can't comment on your problems with getting
> changes in the _devel tree since I've only recently started following
> the 4xx conversations and have never been involved with 4xx until
> a little while ago.

I would expect a development tree to contain non-working and non-tested
stuff. It becomes very help full to see things that get tried but don't
work in the history of a file. It makes a lot more sense to use the version
history to document quirks in hardware than to start putting comments in the
source on what does and doesn't work.

I would sure not want to work for 4-5 weeks between pushes. I like to be
able to make dangerous changes to code knowing that I can always fall back
to a few day older version that sort-of worked.

> > Any particular reason you are keeping things "close to your chest"? I know
> > it is nice to be able to go through and makes changes where ever you
> > like without having to be confronted with them every checkin/merge, but
> > since there are change that will at least change the file structure of
> > other boards it seems like it should be kept more in the open.
>
> The first pass of the core 440 support has no changes that affect the
> file structure of other boards (assuming you are concerned about 40x).
> Again, this is I how do _devel work...I code some logical set of
> functionality (in this case core + onboard serial/emac), make sure it's
> pretty enough that I'm not embarassed, and then I push it out.  I've
> also been asked not to push until paulus is satisfied with the low-level
> booke support.

I am sure most of us are understanding of potentially embarrassing code
and we may just lend a hand cleaning things up. It seems like a lot
of embarrassing code slips past people when it just works.

> In my years of contributing to Linux/PPC, this is the first time I've
> had someone question how/when I contribute my work back.  I've always
> pushed stuff out as soon as it makes sense.

It looks like Eugene wants to help try things out and he has hardware
and as long as you are the only one with the source he can either wait
or start redoing what you have already done.
In the past it may have been MVista got boards ahead of the rest of the
market, but it seems like the boards are hitting the rest of the world
the same time you get them. If some of those people with the boards
are capable of helping to bring them up or cleaning up the source (think
kernel janitors), then it starts to make sense to push stuff out as
soon as it is written.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/