Hi,

tl;dr the commonly needed files for /etc are now [magically] present in Rumprun instances, i.e. you don't have to supply stubetc as a block device to get /etc populated.

I added a tool called genfs. It takes a destination object file name as a parameter, and also one or more directories. Linking the resulting object to the unikernel image by baking or explicit linking via cc will make the files in the directories available at runtime.

The advantages of the approach+implementation:
* data is "zero copy", i.e. it's loaded into memory exactly once
* depends only on rumpvfs, not on a file system or blk device component
* does not introduce new mechanics to the user interface
* does not depend on new external tools, just the cross-toolchain

The tool is also installed as tooltuple-genfs (e.g. x86_64-rumprun-netbsd-genfs), so you can use in your own setups. If you want to use assimilated bake configs, but don't want the by-default /etc for whatever reason, simply nuke -lrumprunfs_base.

So does this change obsolete block devices? All files supplied via genfs, even though they're "zero copy", are still loaded into wired memory. Data on block devices is paged in and thrown out of memory as needed. Therefore, if you need gigabytes of not-very-often accessed data, you can take a wild guess at which scheme is better. However, if you need just a few files (like passwd), want to optimize for resource consumption, and don't need permanent storage, you can now entirely leave out the piggy-sized regular file system and block device drivers. So, you essentially get convenience and a potential tradeoff.

Let's give it a week or so for comments about naming and in general things to settle in before starting to change instructions for rumprun-packages. The old instructions will still work fine, the stubetc file system will simply be mounted on top of the builtin /etc. The minimum short-term work is to install the default /etc so that it's easy to create customized versions of the contents ... but I've just about had enough of makefiles for 2016 already.

  - antti

Reply via email to