[klibc] mkinitrd integration strategy?

[Erik van Konijnenburg]

How should mkinitrd integrate with the initramfs that
comes with the kernel?

At the moment, mkinitrd can simply provide an /init
script and take over with the contents of its own cpio
file available.  /init then loads some modules,
plays with mdadm, lvm, cryptsetup, creates some device
nodes, mounts a filesystem, switch root, done.  Integration
is not an issue.

That changes when more of the kernel moves to user space:
if ACPI tables only work due to an executable in the kernel
provided initramfs, then mkinitrd can no longer ignore what's
in the kernel initramfs.  At the same time, it seems difficult
to make the kernel initramfs a complete replacement for mkinitrd:
you would not want to pull stuff like cryptsetup into the kernel
compilation.

Thus, we need to find a way to have an initramfs filled partly
with files that come with the kernel, partly with files that come
from mkinitrd, and to hand over control between both camps
at the right time.  And it needs to be flexible enough to cope
with an ongoing migration of initialisation processes from
kernel space to user space as new kernels are released.

Has anything already been done in this area, is it something best
left until incorporation into the kernel is a bit nearer,
or something that can be usefully addressed now?

Regards,
Erik