Re: Pruning the source tree (idea)

[Jesper Juhl <jesper.juhl@gmail.com>]

On 9/11/05, Tom Watson <tsw@johana.com> wrote:
> In downloading the whole source tree for the 2.6 kernel, I note that
> there is quite a bit of code relating to architectures other than the
> one I'm using.  While this is a "good thing", it does take up space and if
> I search for something in the kernel (grep, or some such), the non-used
> architectures can take up additional time.
> 

The arch specifics don't take up /that/ much space : 

juhl@dragon:~/download/kernel/linux-2.6.13/arch$ du -hc --max-depth=1
1.7M    ./sh
1.7M    ./um
4.6M    ./arm
722K    ./frv
5.7M    ./ppc
2.7M    ./i386
1.5M    ./cris
801K    ./m32r
2.5M    ./ia64
4.3M    ./m68k
4.7M    ./mips
901K    ./s390
474K    ./v850
637K    ./sh64
1.6M    ./alpha
930K    ./arm26
333K    ./h8300
2.5M    ./ppc64
1.3M    ./sparc
1.7M    ./sparc64
1.7M    ./parisc
1.2M    ./x86_64
505K    ./xtensa
745K    ./m68knommu
45M     .
45M     total

juhl@dragon:~/download/kernel/linux-2.6.13/include$ du -hc --max-depth=0 asm-*
763K    asm-alpha
3.1M    asm-arm
515K    asm-arm26
2.4M    asm-cris
551K    asm-frv
177K    asm-generic
447K    asm-h8300
1.1M    asm-i386
1.2M    asm-ia64
583K    asm-m32r
881K    asm-m68k
832K    asm-m68knommu
2.7M    asm-mips
687K    asm-parisc
1.3M    asm-ppc
884K    asm-ppc64
631K    asm-s390
960K    asm-sh
443K    asm-sh64
900K    asm-sparc
880K    asm-sparc64
540K    asm-um
535K    asm-v850
768K    asm-x86_64
723K    asm-xtensa
24M     total

So we are talking about less than 100MB, and it's even fairly simple
for you to clean it out by hand if you want. I must admit I don't see
the point of having to maintain such a makefile target.  If you want
to delete the archs that don't matter to you, fine, just do that by
hand then or write a small script for it.


> A proposal:
> Have a top level make target that prunes (deletes summarily) the
> unwanted architectures from the source tree.  This should be able to be
> done before, or after a config step, but might not be allowed after the
> first make.  Of course, this step is optional, but for those of us who
> only have a single machine type, it would save a bunch of time.
> 
Submit a patch to implement it then.


Personally I don't think this matters or is a good idea.

It doesn't save that much space (<100MB doesn't matter much with the
several hundred gigabyte HD's of today), and it's easy for someone to
delete locally, by hand, if they want to.

As for the "it speeds up grep" argument, that doesn't hold water, you
can just use the --include and --exclude arguments for grep to only
search relevant dirs.

Including a makefile target that does this would also add one more
thing to maintain and keep working for little gain.

There's also the issue of patching the kernel post-pruning. When you
want to upgrade the source of a pruned kernel, lots of the patch for
the next kernel version won't apply any longer.


No, let's not do this, is my oppinion..


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/