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