klibc only initramfs

[Michael Tokarev]

Goswin von Brederlow wrote:
> Hi,
> 
> I googled a bit and found this old mail about a klibc only initramfs:
> 
> http://lists.debian.org/debian-kernel/2006/07/msg00400.html
> 
> I would really like to do this and it has been close to 4 years since
> that mail. But it doesn't look like there has been much progress or not
> in the right direction. Looking at my initramfs I see:
> 
> % ls lib
> cryptsetup/                            libm.so.6
> klibc-zUXi_KjK5ZQAIyc8jlwme9T6a4U.so*  libncurses.so.5
> ld-linux.so.2*                         libpopt.so.0
> libc.so.6*                             libreadline.so.5
> libcfont.so.0                          libselinux.so.1
> libconsole.so.0                        libuuid.so.1
> libctutils.so.0                        libvolume_id.so.0
> libdevmapper.so.1.02.1                 modules/
> libdl.so.2                             udev/

Apparently the initramfs contains _two_ different libc implementations.
...

[]
> Could we build stripped down versions of those tools (and libs as
> required) build against klibc? I certainly see no need for ncurses in my
> initramfs. Building a klibc based initramfs that then includes libc6
> (and even busybox) as well seems rather stupid. One without klibc would
> be smaller then.

May I ask this question the other way around:

Why maintain two sets of tools and libraries while one set is more
than enough already?  Why we need/want klibc to start with, while
regular glibc and regular tools do the work just fine?

I use glibc-based initramfs (with busybox) since first days when
initramfs were introduced in kernel.  I booted even the less capable
machines (i486 with 16Mb memory) with it without any issues.  I don't
see any reason to maintain another set of tools just for initramfs.

In previous life there was an argument about whole thing fitting a
single floppy drive.  But nowadays a) floppies are gone, and b)
kernel itself does not fit in a floppy anymore.

Also, I heard people saying that klibc-based initramfs is somehow
faster than glibc-based.  Maybe this is partially true, because the
bigger the initramfs is, the more time it requires to load by a
relatively dumb and slow boot loader (esp. for slow network-based
boots).  But even here, in most cases the difference is small and
does not justify the amount of work needed to support the second
set of tools/libraries.

Just an opinion....

/mjt