Re: Merge strategy for klibc
From: Antonio Vargas
Date: Wed Mar 22 2006 - 09:45:40 EST
On 3/22/06, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> Followup to: <Pine.LNX.4.64.0603202228441.17704@xxxxxxxxxx>
> By author: Roman Zippel <zippel@xxxxxxxxxxxxxx>
> In newsgroup: linux.dev.kernel
> > You forgot to provide any information (at least a summary) about what this
> > is and how this will work. Please don't assume everyone is familiar with
> > it.
> > There is one major question: how will this interface to distributions?
> > How can distributions add their own initializations and configurations or
> > are they going to put an initrd on top of the kernel initrd? If this will
> > have a kernel and a distribution part, it poses the question whether klibc
> > has to be distributed with the kernel at all (a libc has a standard API
> > after all) and the kernel just provides the kernel specific parts to
> > whatever the distribution provides.
> Okay... quick summary (again)...
> klibc is a small libc, small enough that it provides negible (or even
> negative) overhead to bundle it inside the kernel binary.
> The kernel tree part is there so that we can rip out in-kernel code
> without breaking compatibility, or requiring a distribution-provided
> initramfs. In the future, we could consider retaining certain
> binaries in the rootfs and have "on-demand userspace" by the kernel,
> e.g. to do partition enumeration in userspace in a
> backwards-compatible manner.
> The default build provides a single binary called kinit, which is
> (modulo any bugs) equivalent to the in-kernel root-mounting code, with
> all its variants (initrd, nfsroot, load ramdisk from floppy, yadda
> yadda.) The existence of kinit allows the in-kernel code to be
> removed without actually removing a feature. Hence, the reason to put
> this in the kernel tree is to make sure there is zero impact on
> If the distribution uses initramfs directly, kinit goes unused. The
> klibc code is also available as a standalone distribution, which at
> least Ubuntu is currently using to build a custom initramfs. Because
> the kinit code is still userspace, it can share considerable amounts
> of code with the standalone klibc utilities collection; in fact most
> of the kinit pieces are available as standalone binaries which can be
> weaved together by scripts or other C code.
> The advantages of moving this code to userspace, thus is:
> - Simpler programming model (harder to screw up)
> - Easier to share code with distribution-customized setups
> - Code can be tested as standalone userspace binaries at runtime
> A lot of the benefit is lost if, like now, there is a piece of code
> which has to be written for kernel-mode programming, separate from
> anything else and not testable except through a tedious kernel boot
ISTM that we are (finally? ;) moving piece by piece to a mixed
monolothic+microkenel, or rather that many of the things that were
first implemented in-kernel (on linux or other unixes) are being
slowly jettisoned to a kernel-provided userspace. All in all this is a
good step forward :)
Regarding helping test/develop this, is there any small distro already
using klibc for such purposes? Maybe you, hpa, could share you klibc
testing rig? This looks ripe for a qemu-based testing at the moment,
not being performance critical like many other current developments...
Greetz, Antonio Vargas aka winden of network
Every day, every year
you have to work
you have to study
you have to scene.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/