[lkml]   [1997]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Packaged Kernel

To throw some numbers into the discussion, in an un-tarred source tree,
here's how the architecture specific code breaks down (in terms of size):

i386: 958kB
alpha: 634kB
sparc: 1240kB
mips: 487kB
ppc: 507kB
m68k: 2504kB
sparc64: 463kB

arch specific code: 6793kB
totatl source tree: 27726kB
(I just got these by doing 'du' in the arch and include directories -
kernel 2.1.21 - no .o files or anything , just the raw untarred source).

As you can see, the average person will use about 6MB storing code that
they will never use.

Also the drivers sub-tree uses 13799kB, and as with the architecture
specific stuff there's a lot of code in there that may never be used.

Everyone has benefited from increased hardware support, but if every
driver for every single device is included into the kernel we're going to
see incredibly large source trees. As an example consider this:
About one year ago, the current development kernel was 1.3.55 - the size
of the tgz'ed source was 3.7MB 2.1.21 comes in at just under 7MB.

Now I'm not advocating that we split everything up into tiny pieces, that
may simply not be feasible especially with regards to applying patches (I
certainly wouldn't want to go around trying to find individual
patches for each of my device drivers), but something needs to be done.

Perhaps what is needed is tighter controls on which drivers are included
in the kernel (ie: based on how many people use them), and consideration
for how one can include drivers not in the main source tree easily (with
minimal patches to kernel source files).

And now back to lurking...

Michal Ostrowski

 \ /
  Last update: 2005-03-22 13:38    [W:0.047 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site