[klibc] mkinitrd integration strategy?
daniel at dthaler.de
Sun May 29 12:32:45 PDT 2005
Erik van Konijnenburg wrote:
> 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
> 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.
You can load 2 initramfs archives: One that is built into the kernel
binary _plus_ a second one loaded by the bootloader like an initrd.
The built-in archive is unpacked first, meaning that files which are in it
can be overwritten by the second one.
More information about the klibc