On Thursday, 15.10.2015 at 08:31, Andrew Stuart wrote: > Is there any value to using initrd/initramfs for the initial ram file system? > These seem to be the “standard” mechanism used by bootloaders for adding an > initial ram based file system to a kernel. All bootloaders support initrd and > initramfs.
Initrd and its successor initramfs rely on bootloaders/firmware using the Linux boot protocol. It may turn out at some future point that "the world is all Linux", at which point we may implement some of the (many) Linux boot protocols. Until then, I'm trying to go for a more general solution which is independent of any bootloaders and the filesystem data can be used in-place. > The nice thing about initramfs (which replaced initrd) is that you can pass > multiple initramfs files to the bootloader which will then overlay the > filesystems on top of each other which allows a base file system image to > remain the same and you just pass in a second initramfs to modify any > specific files you want customised. We should be able to do something similar using NetBSD unionfs. Needs more thought about how it would work in practice. > initramfs/initrd also separates the initramfs from the kernel meaning no need > to recompile the rump kernel for changes to ramfs filesystem, just make a new > initramfs or add an additional initramfs overlay with just the modified files. If you want to separate your data from the unikernel you can just use an external filesystem on a block device. Right now we're missing something that lets you get some data in *with* the unikernel, not separated from it. In any case this solution won't require a recompile, just a rebake.
