Messages in this thread | | | Date | Wed, 22 Mar 2006 15:47:34 +0100 | From | "Antonio Vargas" <> | Subject | Re: Merge strategy for klibc |
| |
On 3/22/06, H. Peter Anvin <hpa@zytor.com> wrote: > Followup to: <Pine.LNX.4.64.0603202228441.17704@scrub.home> > By author: Roman Zippel <zippel@linux-m68k.org> > 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@gmail.com thesameasabove@amigascne.org
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |