Jamie Lokier wrote:

quoted text
> Neil Horman wrote:
>> I've not looked at the figures lately, but how much space does the
>> dhcp client and nfs root code take up in the kernel these days?
> 
> About 4k apparently.  See the difference from "400k compressed?".
> Also, uncompressing that may add 0.5 second boot time on a slow CPU :-)


I just tried to get some actual numbers for the size increase by looking 
at an actual initrd I had lying around.  If I just look at some some of 
the largest files needed for a initrd, they use 800kBytes:

ls -l bin/busybox lib/ld-uClibc-0.9.28.so lib/libuClibc-0.9.28.so
-rwxr-xr-x 1 root root 499804 2007-01-21 18:17 bin/busybox*
-rwxr-xr-x 1 root root  19492 2005-12-27 12:15 lib/ld-uClibc-0.9.28.so*
-rw-r--r-- 1 root root 312136 2005-12-27 08:46 lib/libuClibc-0.9.28.so

All files are stripped ARM9 binaries and as you can see, the C library 
is uClibc.  And compressed it is roughly about 400kBytes:

tar cvfz - bin/busybox lib/ld-uClibc-0.9.28.so lib/libuClibc-0.9.28.so | wc -c

422789

The in kernel BOOT/DCHP client and NFS root code increases the size of
the compressed kernel by slighty less than 8kBytes.  The 4k number was
just for turning off BOOTP/DHCP (IP_PNP).

 > I must admit that a solution which makes the effective kernel size

quoted text
> 800k larger (your figure) doesn't look like a good standard to me.
> 
> If that was the "standard", I'd be tempted to add a MAC address driver
> hack to the kernel to save the space :-)

So the numbers aren't quite as bad, but it is a 50 time increase in 
overhead to do things "right".  For a kernel which is 1.5Mbytes it is 
"only" a 27% increase in total size though.

Of course, using busybox is a bit of an overkill, it should be possible 
to just port the in kernel BOOTP/DHCP client and NFS root code so that 
it is statically linked with klibc and put in an initrd.  If we assume 
that the useful parts of the code stay the same size, it should compress 
to about 8kBytes of initrd instead of 8kBytes of compressed kernel 
image.  But code running from an initrd will need a stdio library with 
printf and a bunch of other library functions.  After taking a quick 
look at klibc it seems that it would add something like 10-20kBytes 
compressed size to a normal application.  So that would only be a 2-3 
time increase in size which is much more acceptable to me.

Actually, just looking at the filenames in the klibc source, it seems 
that it does have a DHCP client and some NFS root code already.  An ARM9 
"kinit" binary is about 75kBytes, and I'm not sure if it includes the 
DHCP client or the NFS root code.  But it means that it's probably 
possible to replace the in kernel code with klibc as is for only an 
extra 50kBytes or so of increased compressed size.

Looks interesting, any year now...

   /Christer














--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html