Re: klibc only initramfs
Goswin von Brederlow wrote:
> I googled a bit and found this old mail about a klibc only initramfs:
> 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....