[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] Re: [klibc] initrd / initramfs future



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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]