Re: klibc and logging

[Erik Andersen <andersen@codepoet.org>]

On Tue Aug 13, 2002 at 04:04:59AM -0400, Alexander Viro wrote:
> We do have nfsroot support in the kernel.  If we are going to move it
> into the userland, we _must_ have the code for that.  "Use glibc" is
> laughable - try to link anything statically against that dungpile and
> see what size you'll get.

Using the version of mount from util-linux-2.11n: 

Staticly linked vs glibc 2.2.5:
    $ ls -l ./mount
    -rwxr-xr-x    1 andersen andersen   533912 Aug 13 03:41 ./mount*

Staticly linked vs uClibc 0.9.14:
    $ ls -l ./mount
    -rwxr-xr-x    1 andersen andersen   115844 Aug 13 03:40 ./mount*

Busybox mount w/NFS enabled, statically linked vs uClibc 0.9.14:
$ ls -l ./busybox
-rwxr-xr-x    1 andersen andersen    62628 Aug 13 03:46 ./busybox*

And uClibc's RPC code accounts for 33k of the 62k...

> Said that, we don't need anywhere near the full RPC support for nfsroot
> and I'm not sure that we want it in libc even if it will be implemented.
> "Use -lrpc" is perfectly OK.
> 
> Stuff needed for nfsroot
> 	a) is purely sequential (full-sync)
> 	b) we need 2 or 3 RPC calls
> 	c) we can open-code marshalling for these
> IOW, the most complex part of that is handling of timeout and possibly -
> logics with retransmit.  Other than that it's filling an array, doing
> sendmsg(), waiting for reply, and checking several words in received array.

I would love to see an example of how to do an NFS mount w/o
resorting to the C library at all.  Plainly, having generic RPC
code in the C library sucks, even if you trim it down.  Having
the entire NFS mount process live in application space, and not
in the C library, is clearly a win....

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--