User: Password:
|
|
Subscribe / Log in / New account

klibc

klibc

Posted Sep 16, 2008 17:29 UTC (Tue) by katzj (guest, #23350)
Parent article: KS2008: Bootstrap code

The other reason glibc ends up being pulled into the initramfs is that distributions don't want to have multiple copies built of all of the tools used in the initramfs. When "all of the tools" was an all-in-one tool that loaded some modules and did mount(2), that wasn't such a big deal. But once you get to wanting to do raid, lvm, encryption, network setup, nfs, nbd, iSCSI, etc you end up with a much longer list of binaries. And it just means more bits on disk, more things to have to build and inevitably more bugs to track down.


(Log in to post comments)

klibc

Posted Sep 16, 2008 18:48 UTC (Tue) by drag (subscriber, #31333) [Link]

that's why it's important to be modular.

With Debian's initramfs, for example, the packages for NFS, uswsusp, dm-crypt, etc will install their own scripts for pulling in binaries from the file system and init scripts to the /usr/share/initramfs/ and get those included. Then when you install those packages the initramfs-based initrd is rebuilt.

This way your only including support for things that are installed and your probably going to want to use. If you don't have uswsusp support in your OS then you don't have it in your initrd.

klibc

Posted Sep 16, 2008 21:27 UTC (Tue) by jengelh (subscriber, #33263) [Link]

And Redhat's initramfs is anything but modular. Heck, it even replicated a lot of features in its "nash" thing, like raidautorun, which, ahem, got obsoleted like when mdadm came to life.

klibc

Posted Sep 17, 2008 9:36 UTC (Wed) by rh-kzak (guest, #51571) [Link]

I think it's better to have multiple copies built of the tools (=same code) than *duplicate code* in the nash. It's cheaper to rebuild against klibc than maintatin completely separate code in (Fedora/RHEL) nash.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds