Re: [linuxsh-dev] Quick note about drop-in trees

[Greg B. <gb...@po...>]

"M. R. Brown" wrote:
> 
> Let me clarify a bit how a drop-in tree should handle changes from mainline
> - just in case there are still some questions or concerns about keeping the
> code synced.
> 
> Obviously all code local to LinuxSH lives in the drop-in tree.  But what
> about changes that we make to the mainline code that sits outside of our
> realm?  Here's a quick idea of how we could do this:
> 
> - The drop-in tree is designed to supercede the mainline kernel, because
>   we're dealing with experimental code in the first place.  So any files
>   that we touch that live in the mainline have to go into the drop-in tree.
> 
> - Say we make a change to drivers/net/8139too.c (e.g. add Dreamcast BBA
>   support, completely local to LinuxSH).  We copy (add/commit) that file
>   into the drop-in tree, and make our changes there.
> 
> - If the 8139too driver is modified by its maintainer, who sends patches to
>   mainline for the next -pre patchlevel then it's our responsiblity to
>   merge the mainline patches with our drop-in version.

  Right.  This has the effect that the drop-in tree works with exactly
one version of the mainline tree.  This fact needs to be stated in an
obvious place so that people checking out the drop-in tree don't do
the wrong thing accidentally.  Also the exact version involved needs
to be noted somewhere and maintained as part of the merge procedure.

> 
> - When the code has been tested sufficently, we can contact the maintainer
>   and send him patches so that she can send them back to the mainline.
> 
> - Unless the driver needs another change, it has been completely sync'd to
>   mainline and any further changes from mainline can simply be patched
>   against the driver.
> 
> Even the mainline code (outside of LinuxSH) that we affect is negligible,
> so the drop-in tree still remains considerable smaller than the entire
> kernel tree.

  Sure, and this is it's primary attraction.

  Now, does the drop-in tree get dumped on top of the mainline tree
or does it go into a sibling directory?  Both approaches have major
problems.  On-top ends up with massive '?' results from "cvs -n up".
Sibling has problems with Makefiles (not solved until kaos' new kbuild).

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.