Re: [Linux-mips-kernel] Whole tree or no whole tree.

[Paul M. <pm...@mv...>]

On Mon, Jun 25, 2001 at 03:45:32PM -0700, Pete Popov wrote:
> >Putting a whole tree in CVS will make it a maintenance nightmare, and ta=
ke
> >away from real development time. If certain items (like pcmcia) need to =
be
> >added into the tree, they should be added in as they're needed.
> >
> >Importing an entire tree so development can be done on some small part of
> >the tree seems kind of wasteful. If patches for the small parts (outside=
 of
> >the MIPS portion of the kernel, such as drivers) are necessary, then it'd
> >be more beneficial to try and get them pushed into Linus' tree then worry
> >about dragging them around in our tree..
> >
>=20
> Sending new drivers, whether pcmcia or network or any other driver, to=20
> Alan Cox or Linus probably makes the most sense. However, the problem=20
> then is that the linux-mips tree will hardly ever be bleeding edge and=20
> up to date with any given board. For example, I'm doing work on a system=
=20
> on a chip which includes quite a few peripherals. Even though these=20
> periperals are "mips specific", since they are part of this mips soc, it=
=20
> still make sense to put their drivers in the appropriate directory --=20
> like drivers/net driver/pcmcia, etc. If I only push those new drivers to=
=20
> Alan or Linus, then the linux-mips tree will have to wait until these=20
> drivers are a) accepted and b) we pull down the changes from the stock=20
> kernel.  Thus, at any given time the linux-mips tree will not have all=20
> the bleeding edge code that developers might/will be interested in.
>=20
Another advantage of the drop-in tree approach. If you have new drivers that
need merging into the tree, they can be added under the appropriate location
without us having to copy the entire subsystem over. All that's necessary
at that point is retaining the Config.in and Makefile so it can be kept up
to date, and so the new driver(s) can be added into them. (Maintaing a
drop-in Configure.help would be useful too.. could just be appended to the
current one).

New drivers should be sent to Alan, though they should only be sent to
Alan after they're sitting comfortably in the linux-mips tree. If we start
sending code directly into Alan's tree, then we get into the issue you
just mentioned regarding our up to date tree having to play catch up.

I was simply noting that it'd be faster for small fix-ups and such to be
pushed into the kernel directly instead of us having to track them in our
tree. For example.. say you have a board that requires a 3 line hack to the
ne2k driver.. should we start carrying around the entire ne2k driver, or
should we try to get the 3 line hack into the driver but make sure that it's
a carefully thought through hack that doesn't come off as a cheap hack.
If it becomes an issue where a necessary hack to a third party driver is
crucial for operation but the change has no chance of getting into the kern=
el,
then it'd be justifiable to keep an up to date copy of the driver in the
tree with the hack applied.

My only point is that we should be weary about what we carry around in the
tree. Keeping unnecessary source in the tree means more maintenance.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.