[klibc] The future of klibc in the kernel

[Aaron Griffin]

On 10/3/06, Jeff Bailey <jbailey at ubuntu.com> wrote:
> 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.

I agree 100%.  Having klibc in or out of the kernel will not affect
the way in which Archlinux kernels boot.  In fact, having it in the
kernel might make things more difficult to package based on how we do
it now... but I'm speculating.

The only thing I care about is klibc existing at all.

> 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 was able to compile udev without glibc.  We also do not use busybox,
but use dash distributed in the klibc utils, with a handful of minor
hand-written utilities - most are special case.

If I were to make a feature request it would be enough support to
compile libdevmapper and lvm2 under klibc - I cannot recall offhand
what is missing, but I can check if anyone is interested.

> 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.

Same.  The Arch kernels won't boot without klibc.  It would be nice to
disable the in-kernel init, if only to trim the resulting bzimage a
tad.

Aaron Grifin