netdev - Re: [PATCH] dnet: Dave DNET ethernet controller driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090313002155.GB13764@localhost.localdomain>
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