[klibc] The future of klibc in the kernel

[H. Peter Anvin]

Jeff Bailey wrote:
> 
> I think we're suffering from a slight dogma difference.
> 
> The kernel folks want everything involved in bringing up the system to
> user init to be included.
> 
> The distro folks don't care.  We get packages from everywhere anyway.
> One more is hardly a problem.  The tradeoff in this case is decently
> modular kernels and a single initramfs that does NFS booting, Harddrive
> booting, and other crazy thing we've cooked up.
> 
> Having it in the kernel hasn't been a pre-requisite for using it in
> Ubuntu and Debian.  We depend on udev, module-init-tools, klibc, and
> busybox to get the system up and running.  
> 
> It would be really nice to make that not also draw in glibc at some
> point.  Right now I think we pull in glibc for udev and busybox.
> 
> I guess what might be a nice patch to the kernel is to make the
> in-kernel bits that klibc replaces configurable.  That way the distros
> could just disable them and not worry whether they're there or not.
> Anyone using our kernels is using a setup that doesn't have any device
> drivers loaded in anyway, so they're already forced to use this.
> 

This is an interesting perspective, and maybe something that *could* get 
into even the 2.6.19 kernel would be to make all the non-initramfs code 
an option.  That would probably be relatively noncontroversial.

	-hpa