Re: [BK PATCH] klibc for 2.5.64 - try 2

[Eric W. Biederman]

Russell King <[e-mail]> writes:

> On Fri, Mar 07, 2003 at 07:06:42PM -0700, Eric W. Biederman wrote:
> > I agree ipconfig.c works well for development.  Last time I played with
> > something like this it should not be hard to get the entire initrd
> > binary down to 30K-40K.   I think you can probably do it in 16K but...
> > 
> > As far as equivalent functionality there is already a dhcp client and
> > a mount client in busybox.  So in the worst case someone it will
> > take just a bit of glue to put these things together.
> 
> You didn't read my previous emails on this very subject.  When you try to
> separate the dhcp client and mount client, you need some way to pass the
> information about which NFS server and path to mount to mount from dhcp.
> I have yet to find any DHCP client which allows this without the use of
> a shell and some parsing, which pushes the initrd through the roof.

I agree they both the dhcp client and the nfs mount need to be in the
same binary.  With busybox they already are so it should just take
some glue code to have the magic work.

The last time I worked on something like this I put a dhcp client, and
a tftp client in a single binary, my compressed initrd was only 16K on
x86.  And I had a complete network boot loader using the linux kernel.

Now the kernel is so big and bloated it has not been practical to use
it.  So my effort has mostly been concentrated on etherboot.  Which
is essentially a mini-kernel that just focuses on being a network boot
loader.  And with etherboot I can get a udp/ip stack. With dhcp and
tftp support, and an eepro100 nic driver into 38K on an Itanium (The
platform with possible the most bloated binaries known to man).  On x86
with an eepro100 driver I can usually get it down to around 16K.  (All
sizes represent self decompressing executables).

And in etherboot there is support for mounting a nfs filesystem, and
reading a kernel off of that.  Which makes it extremely relevant for
the question of how small can you get when replacing ipconfig.c

In truth putting the dhcp and mount clients in separate binaries
never occurred to me as a practical strategy.

> > > klibc provided a way, but if that isn't going to be merged and this stuff
> > > made to work for 2.6, then I think we must keep ipconfig.c and
> > > nfsroot.c.
> > 
> > Either klibc or alternative user space implementation.  There is no
> > reason that magic has to happen in the kernel.  The only thing has
> > to be implemented is a way to smush a kernel and an initrd together.
> 
> klibc is a user space C library, which incidentally supports ARM Thumb
> binaries natively.  Here's some of the klibc ARM (non-thumb) executable
> sizes:
> 
> -rwxrwxr-x    1 root     root         784 Oct 21 16:22 bin/chroot
> -rwxrwxr-x    1 root     root        4288 Oct 21 16:22 bin/dd
> -rwxrwxr-x    1 root     root        1892 Oct 21 16:22 bin/fstype
> -rwxrwxr-x    1 root     root       21348 Oct 21 16:22 bin/gzip
> -rwxr-xr-x    1 root     root        1340 Oct 21 16:22 bin/init
> -rwxrwxr-x    1 root     root       55396 Oct 21 16:22 bin/ip
> -rwxrwxr-x    1 root     root        9260 Oct 21 16:22 bin/ipconfig
> -rwxrwxr-x    1 root     root        2340 Oct 21 16:22 bin/mkdir
> -rwxrwxr-x    1 root     root        1956 Oct 21 16:22 bin/mkfifo
> -rwxrwxr-x    1 root     root        1988 Oct 21 16:22 bin/mount
> -rwxrwxr-x    1 root     root         732 Oct 21 16:22 bin/pivot_root
> -rwxrwxr-x    1 root     root       61412 Oct 21 16:22 bin/sh
> -rwxrwxr-x    1 root     root         900 Oct 21 16:22 bin/umount
> -rwxrwxr-x 1 root root 54996 Oct 21 16:22 lib/klibc-0kmXIFHd5q4HQkCE6r3itw.so
> 
> 
> Note: all these utilities have been written to be as small as possible,
> and not all of these are absolutely required for a single-configuration
> system.  There is very little code shared between these utilities.
> 
> Even gzip has had lots of crap removed from it to shrink it down to size.
> `ip' is a hugely bloated way to configure IP networking - that binary
> only supports link, addr, and route functions.
> 
> I challenge anyone to find binaries that are smaller than these, but
> contain the same functionality (ie, no surprises that something doesn't
> work the way it should do.)  Note: busybox is not functionally the same.
> Been there already.

I'm lost.  Why is there a complete userspace here?  I guess this
explains why klibc is not useful yet.  This is definitely not a route
for what is required to just replace the kernel pieces like ipconfig.c

I knew something was fishy when we got beyond having a single
executable.  This is where I mumble that it was once possible to
run unix in 64K. (32K kernel 32K user space)  So why can't we get
small binaries anymore?

> Things the current klibc setup is able to do:
> 
> - bringing up networking.
> - detecting a local filesystem type.
> - mounting a _local_ filesystem.
> - gunzipping a ramdisk image from a device and loading it into a ramdisk.
> 
> Things klibc stuff can't do at present:
> 
> - be configurable from the kernel command line.  If something goes wrong
>   with the boot, you need to rebuild the early userspace image to do
>   something different.
> - mount NFS-root filesystems.
> - be as small as the current kernel solution.  Current early userspace
>   weighs in at 220K (uncompressed) on ARM, or a 97K gzipped ext2fs image.
 
That is definitely still a heavy weight.  Not to bad for a general
purpose setup but not really good either.

> A solution for the first requires all the existing infrastructure in
> the kernel (which traps things like "ro", "root=" and so forth) to
> be removed.

Or a different set of option names be used in the interim.

> A solution for the final point is possible - you combine everything
> together into one large image, get rid of the shell, and produce one
> honking monolitic kitchen sink that couldn't care whether you have
> NFS support in the kernel or not.

Exactly.  And you build it for the specific purpose of just
configuring the system.  And by not handling the general case you
should be able to get another significant size reduction.

> Please note - I have a working setup here which:
> 
> - decompresses the initramfs ext2 image from a MTD flash partition
> - sets up networking using dhcp
> - decompresses the real root ramdisk into another ramdisk
> - detects the type of the filesystem
> - mounts the filesystem
> - pivot-root's to the root filesystem
> - starts init
> 
> This works for me.  Others milage will vary drastically because klibc
> needs more work.
> 
> Oh, I may seem to be enthusiastic about klibc.  I haven't worked on it
> since October last year, mainly because it didn't seem to be going anywhere
> fast (like, into the kernel.)  I'm not intending spending anymore time
> on it until there's some improvement in this area, which would allow more
> stuff to happen in klibc.

Reasonable I guess.

Eric