linux-mips-kernel — Developers list to discuss MIPS issues

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.

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

[Pete P. <pp...@mv...>]

Paul Mundt wrote:

>On Mon, Jun 25, 2001 at 12:30:22PM -0700, James Simmons wrote:
>
>>Okay I see some people are not happy with the drop down tree idea. I know
>>not to many people with the idea but I'm willing to put it to a veto for
>>what to do. If you want me to place a whole tree in CVS then I will.  
>>
>
>Putting a whole tree in CVS will make it a maintenance nightmare, and take
>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..
>

Sending new drivers, whether pcmcia or network or any other driver, to 
Alan Cox or Linus probably makes the most sense. However, the problem 
then is that the linux-mips tree will hardly ever be bleeding edge and 
up to date with any given board. For example, I'm doing work on a system 
on a chip which includes quite a few peripherals. Even though these 
periperals are "mips specific", since they are part of this mips soc, it 
still make sense to put their drivers in the appropriate directory -- 
like drivers/net driver/pcmcia, etc. If I only push those new drivers to 
Alan or Linus, then the linux-mips tree will have to wait until these 
drivers are a) accepted and b) we pull down the changes from the stock 
kernel.  Thus, at any given time the linux-mips tree will not have all 
the bleeding edge code that developers might/will be interested in.


Pete

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

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

On Mon, Jun 25, 2001 at 12:30:22PM -0700, James Simmons wrote:
> Okay I see some people are not happy with the drop down tree idea. I know
> not to many people with the idea but I'm willing to put it to a veto for
> what to do. If you want me to place a whole tree in CVS then I will. =20
>=20

Putting a whole tree in CVS will make it a maintenance nightmare, and take
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..

Regards,

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

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

[James S. <jsi...@tr...>]

Okay I see some people are not happy with the drop down tree idea. I know
not to many people with the idea but I'm willing to put it to a veto for
what to do. If you want me to place a whole tree in CVS then I will.  

Re: [Linux-mips-kernel] drivers/pcmcia

[James S. <jsi...@tr...>]

> I think I only need to sync with Ralf, since he syncs up all new files 
> and modifications with Linus.  
> 
> But maybe a better option is to send Ralf the drivers/pcmcia patch, and 
> let him sync it up with Linus the next time he does that.   I've sent 
> him other similar patches before which made their way to the stock 
> kernel (but then again, other patches haven't and only exist in Ralf' tree).

Ralf's tree only synces up every now and then. Usually only ceertain part
sync up actually. Some of the fixes he does in "other" parts of the tree
don't go in. Or they shoudl  go in but are over looked. It is easy to miss
a file when you 10,000+ of them.

> So is Ralf's tree a drop-in tree as well? How did you know that his tree 
> does not include drivers/pcmcia?

Well it synces with linus tree very well but he has a full blown tree in
CVS. I know that pcmcia is not in the tree since I compared both trees. I
keep ralphs tree as well as linus tree on my machine here. Then I do diffs
to compare the two. I compare both trees from time to time to make sure
they are in sync enough. 

Re: [Linux-mips-kernel] drivers/pcmcia

[Pete P. <pp...@pa...>]

James Simmons wrote:

>>It looks like Ralf's tree does have the entire drivers/pcmcia directory. 
>> How about if I commit those?  We'll need many of those files for pcmcia 
>>support anyway.
>>
>
>Of course it has the entire directory. His tree is on top ot Linus tree.
>If you commit them all you will be responisble to keep ALL files in sync
>with Linus and Ralph's tree. This part is what is a PITA.
>

I think I only need to sync with Ralf, since he syncs up all new files 
and modifications with Linus.  

But maybe a better option is to send Ralf the drivers/pcmcia patch, and 
let him sync it up with Linus the next time he does that.   I've sent 
him other similar patches before which made their way to the stock 
kernel (but then again, other patches haven't and only exist in Ralf' tree).

So is Ralf's tree a drop-in tree as well? How did you know that his tree 
does not include drivers/pcmcia?

Pete

Re: [Linux-mips-kernel] drivers/pcmcia

[James S. <jsi...@tr...>]

> It looks like Ralf's tree does have the entire drivers/pcmcia directory. 
>  How about if I commit those?  We'll need many of those files for pcmcia 
> support anyway.

Of course it has the entire directory. His tree is on top ot Linus tree.
If you commit them all you will be responisble to keep ALL files in sync
with Linus and Ralph's tree. This part is what is a PITA.

Re: [Linux-mips-kernel] drivers/pcmcia

[Pete P. <pp...@pa...>]

James Simmons wrote:

>Go ahead. This was not in Ralph's tree. 
>
>On Mon, 25 Jun 2001, Pete Popov wrote:
>
>>The files in drivers/pcmcia are not part of the drop in tree. Can we at 
>>least bring in Config.in and Makefile so we can add options/support for 
>>mips based pcmcia controllers?
>>
It looks like Ralf's tree does have the entire drivers/pcmcia directory. 
 How about if I commit those?  We'll need many of those files for pcmcia 
support anyway.

Pete

Re: [Linux-mips-kernel] drivers/pcmcia

[James S. <jsi...@tr...>]

Go ahead. This was not in Ralph's tree. 

On Mon, 25 Jun 2001, Pete Popov wrote:

> The files in drivers/pcmcia are not part of the drop in tree. Can we at 
> least bring in Config.in and Makefile so we can add options/support for 
> mips based pcmcia controllers?

[Linux-mips-kernel] drivers/pcmcia

[Pete P. <pp...@pa...>]

The files in drivers/pcmcia are not part of the drop in tree. Can we at 
least bring in Config.in and Makefile so we can add options/support for 
mips based pcmcia controllers?

Pete