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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b7fb03d.2090...@msgid.tls.msk.ru
