public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Pruning the source tree (idea)
@ 2005-09-11 21:56 Tom Watson
  2005-09-11 22:20 ` Jesper Juhl
  2005-09-13  9:30 ` David Vrabel
  0 siblings, 2 replies; 4+ messages in thread
From: Tom Watson @ 2005-09-11 21:56 UTC (permalink / raw)
  To: linux-kernel

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.

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.

Thanks

(non subscriber)
-- 
Tom Watson		Generic short signature
tsw@johana.com		I'm at home now.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Pruning the source tree (idea)
  2005-09-11 21:56 Pruning the source tree (idea) Tom Watson
@ 2005-09-11 22:20 ` Jesper Juhl
  2005-09-12 23:24   ` Rik van Riel
  2005-09-13  9:30 ` David Vrabel
  1 sibling, 1 reply; 4+ messages in thread
From: Jesper Juhl @ 2005-09-11 22:20 UTC (permalink / raw)
  To: Tom Watson; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Pruning the source tree (idea)
  2005-09-11 22:20 ` Jesper Juhl
@ 2005-09-12 23:24   ` Rik van Riel
  0 siblings, 0 replies; 4+ messages in thread
From: Rik van Riel @ 2005-09-12 23:24 UTC (permalink / raw)
  To: Jesper Juhl; +Cc: Tom Watson, linux-kernel

On Mon, 12 Sep 2005, Jesper Juhl wrote:

> 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.

"make tags" is your friend.

Then you can navigate the source code with any program that
understands ctags, including vim.

:ta <word>  to find a particular declaration or function
^]          to jump to the function or declaration of the
            word under your cursor
^t          to go back to where you came from

-- 
All Rights Reversed

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Pruning the source tree (idea)
  2005-09-11 21:56 Pruning the source tree (idea) Tom Watson
  2005-09-11 22:20 ` Jesper Juhl
@ 2005-09-13  9:30 ` David Vrabel
  1 sibling, 0 replies; 4+ messages in thread
From: David Vrabel @ 2005-09-13  9:30 UTC (permalink / raw)
  To: Tom Watson; +Cc: linux-kernel

Tom Watson wrote:
> 
> Have a top level make target that prunes (deletes summarily) the
> unwanted architectures from the source tree.

NAK.  I think you underestimate the number people who'd do something like:

1. make prune ARCH=foo
2. make oldconfig ARCH=bar
3. Complain to l-k, their vendor etc. that the kernel is busted.

David Vrabel

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-09-13  9:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-11 21:56 Pruning the source tree (idea) Tom Watson
2005-09-11 22:20 ` Jesper Juhl
2005-09-12 23:24   ` Rik van Riel
2005-09-13  9:30 ` David Vrabel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox