Re: Symbol links to only needed and targeted source files

[Valdis.Kletnieks@vt.edu]

On Wed, 03 Jan 2007 22:14:43 +0100, Pelle Svensson said:
> Hi Sam,
> 
> You misunderstand me I think, I already using a separate output directory.
> What I like to do is a separate 'source tree' with only valid files
> for my configuration. In that way, when I use grep for instance,
> I would only hit valid files and not 50 other files which are
> not in the current build configuration.

This is covered in the Kernel FAQ:

http://www.tux.org/lkml/#s7-7

"The kernel source is HUUUUGE and takes too long to download. Couldn't it be
split in various tarballs?

The kernel (as of 2.1.110) has about 1.5 million lines of code in *.c, *.h and
*.S files. Of those, about 253 k lines (17%) are in the architecture-specific
subdirectories, and about 815 k lines (54%) are in platform-independent
drivers. If, like most people, you are only interested in i386, you could save
about 230 k lines by removing the other architecture-specific trees. That is a
15% saving, which is not that much, really. The "core" kernel and filesystems
take up about 433 k lines, or around 29%.

If you want to start pruning drivers away, the problem becomes much harder,
since most of that code is architecture independent. Or at least, is supposed
to be/will be. There is some driver code which probably should be moved to an
i386-specific subdirectory, and perhaps over time it will be (it will take a
lot of work!), but you need to be careful. PCI cards for example should be
architecture independent. Throwing out the non i386-specific drivers will save
around 97 k lines, a saving of about 6%.

But the most important argument for/against splitting the kernel sources is not
about how much space/download time you could save. It's about the work involved
for Linus or whoever will be putting together the kernel releases. Building
tarballs (compressed tarfiles) of the whole kernel already represents a
considerable amount of work; splitting it into various architecture-dependent
tarballs would dramatically increase this effort and would probably pose
serious maintainability problems too.

If you are really desperate for a reduced kernel, set up some automated
procedure yourself, which takes the patches which are made available, applies
them to a base tree and then tars up the tree into multiple components. Once
you've done all this, make it available to the world as a public service. There
will be others who will appreciate your efforts."

In other words, it won't help as much as you think.  And note that you'd
*really* need to make it config-specific - the instant you change *any*
option in that .config, you're likely now including some newoption.c file
that will fail your kernel build...  Whoops.

Attachment: pgp5k0raphdoA.pgp
Description: PGP signature