On 3/22/06, H. Peter Anvin <[email protected]> wrote:
> Followup to: <[email protected]>
> By author: Roman Zippel <[email protected]>
> 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/
[email protected]
[email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
