A few people have asked why my kbuild-2.5 supports shadow trees. This
is a reasonable question, given the extra code and complexity required
to support them. Why not just use Jeff Garzick's patch for supporting
third party drivers?
If kbuild only had to support add on, free-standing third party code
then Jeff's patch would do the job. But some people have a larger
problem, their code replaces part of the existing kernel. A short list:
kdb Mostly free standing but it updates ~ 18 existing kernel files,
and that is not counting the vmlinux.lds changes in each
architecture.
xfs Almost all free standing but it updates ~ 10 existing kernel
files.
Donald Becker's drivers.
Every one replaces existing kernel code. It is not just
Donald's drivers that have this problem, every new version of
an existing driver falls into this category. Copying the
entire kernel just to patch a couple of files is
unsatisfactory.
Architecture dependent code.
Most architectures have additional and replacement code that
has not been merged into the main tree yet. In many cases if
these patches are applied to the base source tree then the
source will not compile for other architectures.
The aim of shadow trees is to keep a pristine, Linus blessed source
tree. The extra code shadows the base tree, using multiple layers if
that is what you need. I want to be able to compile
i386 from 2.4.4 base
ia64 from 2.4.4 base + ia64 shadow tree
i386 from 2.4.4 base + kdb shadow tree
ia64 from 2.4.4 base + ia64 shadow tree + kdb shadow tree
Repeat for alpha, sparc etc. Add xfs, jfs, ext3 etc. over the above
architectures. When 2.4.5 comes out, replace the base tree, make any
changes required in the shadow files to match 2.4.5 and compile again.
Shadow trees support people developing or using large and relatively
independent update sets. Without shadow tree support you are doomed to
a separate source tree for every combination. That duplicates 120Mb of
source which is bad enough. But the real problem comes when you make a
change in one of the patch sets and then have to extract and duplicate
that change to every other source tree. It gets even worse when you
change the base kernel version, you have to extract all the changes
from each duplicated source tree, build new trees based on the new base
and try to apply the changes from the previous version.
Shadow trees do not completely remove these problems but it does remove
the need to reproduce changes in multiple separate trees. It also
means that upgrading to a new base kernel requires one set of changes
for each shadow tree, instead of for each combination that you are
supporting.
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
