Re: klibc and logging

[Alexander Viro]

On Tue, 13 Aug 2002, Erik Andersen wrote:

> May I suggest that the poor souls that wish to use NFS mounts
> should be statically linking their NFS mount app vs glibc, uClibc
> or whatever.  I see little need for you to recreate that whole
> evil pile of mush...  What happens next week when someone wants
> to get their NFS mount password from LDAP or NIS?  Will you add
> klibc nss support?  Or when someone just needs to have wordexp()
> and regcomp() and....  I think you are on a very slippery slope.
> Keep it simple.  If people want to do stuff that is complex, they
> can pay the price for the added baggage.  Even if people need to
> statically link one app vs uClibc or dietlibc, they are still
> going to get a very small binary.  And they can still include all
> their nasty closed source binary only playtoys in the initrootfs
> linked vs klibc.

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.

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.