[kbuild-devel] Why shadow trees?
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
[kbuild-devel] Re: CML2 design philosophy heads-up
Jes Sorensen [EMAIL PROTECTED]: If Ray wants to fix things, it's just fine with me. I have corrected the Mac dependencies as Ray directed. Eric Does this mean you'll take over maintaining the CML2 rules files Eric for the m68k port, so I don't have to? That would be wonderful. For a start, so far there has been no reason whatsoever to change the format of definitions. The judgment of the kbuild team is unanimous that you are mistaken on this. That's the five people (excluding me) who wrote and maintained the CML1 code. *They* said that code had to go, Linus has concurred with their judgment, and the argument is over. So far you have only been irritating developers for no reason. What I asked you to do is to NOT change whatever config options developers developers felt were necessary to introduce. If you want to change the format of the config.in files go ahead. Messing around with the config options themselves is *not* for you to do, nor are you to impose a more restrictive space for people to work in. If you persist in misunderstanding what I am doing, you are neither going to be able to influence my behavior nor to persuade other people that it is wrong. Listen carefully, please: 1. The CML2 system neither changes the CONFIG_ symbol namespace nor assumes any changes in it. (Earlier versions did, but Greg Banks showed me how to avoid needing to.) 2. The ruleset changes I have made simplify the configuration process, but they do *not* in any way restrict the space of configurations that are possible. By design, every valid (consistent) configuration in CML1 can be generated in CML2. I treat departures from that rule as rulesfile bugs and fix them (as I just did at Ray Knight's instruction). 3. I do not have (nor do I seek) the power to impose anything on anyone. You really ought to give CML2 a technical evaluation yourself before you flame me again. Much of what you seem to think you know is not true. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, Policy Lessons from Recent Gun Control Research, ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
