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

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

Paul Mundt wrote:

>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 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.
>>
>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
>
In other words, it's OK to commit new drivers to, let's say, drivers/net 
in the linux-mips tree?   That would be fine -- I thought that by the 
drop-in approach this wasn't desirable.

>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 kernel,
>then it'd be justifiable to keep an up to date copy of the driver in the
>tree with the hack applied.
>
So do we keep a patch somewhere in this case?    Let me give you an 
example.  The pcmcia client drivers use insl/outsl instructions, 
eventhough pcmcia is 16 bit.  The mips insl/outsl macros do not work on 
my board because it only does 16 bit pcmcia accesses. So I had to 
"ifdef" the io.h file to redefine the insl/outsl macros to use 16 bit 
accesses.  The patch is small, but ugly because it modifies a mips 
global file with a board-specific ifdef. I don't know if Ralf would take 
that patch.  What do you do in this case?  

>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.
>

I buy that argument, I'm just trying to figure out how to work in this 
environment and what's allowed and/or recommended.

Pete

>