Re: Merge strategy for klibc

[Antonio Vargas]

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
> distributions.
>
> 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
> cycle.
>
>         -hpa

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

http://wind.codepixel.com/
windNOenSPAMntw@xxxxxxxxx
thesameasabove@xxxxxxxxxxxxx

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/