Re: Kernel Source Tree Size: Platform Subsets?

Keith Rohrer (
Fri, 27 Feb 1998 17:18:28 -0600 (CST)

And lo, William Stearns saith unto me:
> On a laptop with limited hard drive space I choose to delete the
> other architectures code blocks in arch/ and include/. Doing that saved
> 7-10MB. As it seemed to have no side effects, I put this feature into the
> "buildkernel"* script so that it automatically deletes code from other
> architectures than the one you're building on after it applies your
> patches (for this reason, the script is probably not useful for people who
> cross-compile).
Wow, that's a lot of space. You might want to add the "remove the
unwanted arches" in as an option, rather than an always-on, or even
move that to a separate code ("archclean").

> As for the obvious question, "Will this reduce my download time?",
> the above tool can't affect that. If memory serves, having a
> "linux...i386.tar.gz" was discussed at one point and (rightfully, IMO),
> shot down. Two tars and two patches for each kernel is plenty on
> and mirrors... Those who find the download time too long
> can still patch up from a base kernel.
I agree that splitting the patches is bad; there should be one and
only one patch per kernel rev, to include patches for the entire
kernel. However, splitting the non-patch versions makes a certain
amount of sense, if done in moderation (as seen in numerous other large
packages like emacs, perl(?), ghostscript...); someone's mentioned an
enhanced patch-kernel that will even filter the patch so it applies
cleanly despite missing subtrees. Non-developers can get only what
they need, while developers can mget all the subtrees, so they can
at least look and see if their work impacts any subtrees they don't
use. To keep things in sync, all subtrees ought to share a common
numbering (as they already do); we might want to make LATEST-subdir
symlinks and not actually release new tarballs of unchanged subtrees
every version...

Keith (do mirroring programs grok symlinks?)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to