On Tue Aug 13, 2002 at 12:12:10AM -0700, H. Peter Anvin wrote:
> Okay... I think klibc is starting to get pretty much to the point where
> it will need to be, although I'm sure there will be plenty of bugs once
> we start using it heavily -- and it still needs RPC support code for
> mounting NFS :(
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.
> However, I'm wondering what to do about logging. Kernel log messages
> get stored away until klogd gets started, but early userspace may need
> some way to log messages -- and syslog is obviously not running. The
Umm. Why not just write to /dev/console. If someone is unable
to read from that (VGA, serial, network console, whatever) while
trying to set up an NFS-root, they get to keep both pieces.
-Erik
-- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:31 EST