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

[M. R. B. <mr...@0x...>]

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.

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

For examples of this, please check out the linuxconsole ruby tree
(http://sf.net/projects/linuxconsole) or linux-mips tree
(http://sf.net/projects/linux-mips).

Any problems with this approach?

Marcus