christophe varoqui wrote:
Hello,
I would like to know if initrd is here to stay, now that klibc and
initramfs are ready.
As the multipath-tools maintainer, I'm facing the choice to
1) put the multipath configuration tool in the initrd
* dynamic binary is possible
* storage hba drivers as modules loaded
* no klibc limitations (no mntent for libsysfs ...)
2) put the multipath configuration tool in the initramfs
* small static binary
* storage drivers must be compiled static ?
* udev available ?
Putting it this way, it seems the initrd is the right place for stuff
like lvm2, multipath, mdadm ... but I'd like to be sure before dropping
the provisional klibc support in the tools.
A few of the choices you have up there are bogus, since they have
nothing to do with initrd vs initramfs; you can use klibc with initrd
and you can use glibc, uclibc or newlib with initramfs.
Supporting klibc would be a good idea regardless.
initrd won't be obsoleted immediately; not for several kernel
generations (at least using pivot_root, the "poke a device number into
proc and exit linuxrc" crap might go away sooner.) initramfs is clearly
the way forward, though, in large part because it supports merging of
binaries carried with the kernel and user-provided stuff, which means we
can (finally) move stuff that is currently kernel functionality into the
initramfs.
-hpa
