Hi all, I have implemented support for a baking an in-memory root filesystem into a rumprun unikernel. This is currently on the wip-rootfs branch, mostly because it's Friday and I have to go and see a man about a dog, can't wait around for Travis CI to get its act together :-)
Anyhow, the general idea is as follows: rumpbake now accepts multiple '-R PATH' options. Each -R option adds the contents of PATH to the root filesystem for the unikernel we are baking. This means that we can now run unikernels which only depend on a (smallish) amount of static data with no block devices. Amongst other things, it should simplify things for people who want to run such applications on AWS, and also on bare metal, VirtualBox and whatnot as you don't need any kind of block devices or support for them. Future plans for this functionality / things to think about: 1) I'd like to use this to include a stub /etc directly in the unikernel image *by default*, so that my rump-* "packaging" for nginx and other software does not need to include its own stub /etc. This is also why multiple -R options are allowed, so that you can add to / override the default contents if you wish. 2) The current implementation uses Justin's libuntar. A .tar file is linked in to the image by rumpbake and at boot time this is extracted to the root directory. Note that due to the nature of rumpfs (the root filesystem in use), this is not suitable for large amounts of files. I'd like to replace the root filesystem for rumprun unikernels and use tmpfs instead of rumpfs (well, a CoW squashfs would be best, but NetBSD doesn't have that). Antti: Any gotchas with this? Justin mentioned that there might be a problem with the etfs devices. 3) It begs the wider question of what to do with "rumprun iso". This currently produces an ISO image with a "root" filesystem of its own, mostly so that it can get at the rumpconfig data to configure the unikernel. Also, "rumprun iso" does not actually *run* anything, so it seems like this functionality is in the wrong place. With my support for a baked-in rootfs the extra "root" filesystem for rumpconfig is no longer needed, however the "make an iso" functionality would have to be done in/depend on rumpbake. Thoughts? Martin
