[klibc] initrd / initramfs future

[H. Peter Anvin]

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