lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 12 Mar 2009 20:21:55 -0400 From: Neil Horman <nhorman@...driver.com> To: Christer Weinigel <christer@...nigel.se> Cc: Jamie Lokier <jamie@...reable.org>, David Miller <davem@...emloft.net>, shemminger@...tta.com, s.hauer@...gutronix.de, yanok@...raft.com, linux-arm-kernel@...ts.arm.linux.org.uk, netdev@...r.kernel.org, wd@...x.de, dzu@...x.de Subject: Re: [PATCH] dnet: Dave DNET ethernet controller driver On Fri, Mar 13, 2009 at 12:42:41AM +0100, Christer Weinigel wrote: > Jamie Lokier wrote: > >> 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 > >> 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 > So, I've avoided asking this question, because I didn't want to get off topic, but since it appears we're winding up here, I have to ask what your long term plan is for your final application. I can understand being hesitant to invest in an initramfs when its solely for your intermediate development (even though I think that will pay off for you in the long run), but when your development ends, and you ship a product, how do you plan to implement your application? I would imagine you at least need an initramfs to store, load and run your final application don't you? How do you plan on executing it? Neil > > > > > > > > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists