[klibc] initrd / initramfs future

[Alexander E. Patrakov]

christophe varoqui wrote:
> Hello,
> 
> I would like to know if initrd is here to stay, now that klibc and
> initramfs are ready.

Initrd has the following advantage for distros: you can replace it 
without kernel recompilation.

> 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 ...)

You are free to make uclibc-based initramfs, with all these features.

> 2) put the multipath configuration tool in the initramfs
> 	* small static binary
> 	* storage drivers must be compiled static ?
No
> 	* udev available ?
It is also available in initrd.

> 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.

It's just a matter of convenience for distro-makers.

-- 
Alexander E. Patrakov