On Wednesday, 30.09.2015 at 17:12, Antti Kantee wrote: > The *main* problem with the original proposal was sprinkling another > mechanism along the toolchain. Moreso, it was an inflexible mechanism. It > provided some default (magic) /etc and some additional files on top of that > if you so chose. I can't remember if there was some way of saying "no I > don't want any files thank you very many". A 100kB /etc is pretty huge if > you really want to cut down memory use for a specific use case.
"default magic /etc" was only a proposal, not implemented. And if you didn't want any files you just didn't specify any. > The other problem, at the time, was introducing configuration already at the > bake-stage when config was supposed to happen only at launch-time. That > ideal has gone down the drain, as I've been trying to argue in the > rumpbake-rumprun thread, though some still resist ;) ;) I think it's clear now that a "baked in filesystem" is just another component supplied to rumpbake. Should we add the ability to link in extra components at rumpbake stage without needing to edit rumpbake.conf? The idea is to allow e.g. rumprun-packages to supply prebuilt bake-ready filesystems, so you'd be able to do something like: rumpbake hw_virtio nginx.bin nginx configfs.o datafs.o This is also extensible to any other non-APP components you might want to link in. Regarding configuration at bake stage, I think that such a linked-in filesystem component should be "self-configuring" in the sense that it knows what fstype it contains and a (non-root, for now) mountpoint must be specified to $fstool at creation time. > MFS = FFS. With md(4) we could use any block based file system. FFS just > happens to support the same without md(4). Not sure if we'd want to default > to ext2 (or iso) instead. If yes, should be easy to make happen. > > So, yes, something like $fstool input output. Maybe with [-r rootpath], > where "rootpath" is the "mount point". Should input be a staging directory > or an image file? The former has the advantage of making the process > entirely transparent, the latter has the has the advantage of it being more > likely that users can examine the contents of the image on the host. I'm going to start with just MFS and "input is image file" to get something working, we can improve it later. Keeping the input an image file doesn't force a dependency on fs-utils just yet. > Print a warning if "input" is ridiculously large (>1MB)? Yeah. > Then you can specify "output" in bake.conf with "add" and if you want, > remove the default /etc with a clearly decided and documented name with > "del". See above about being able to add components directly on the rumpbake command line, but otherwise agreed. > Anything else? Not right now, I'm sure something will come up in the process of making it work :-)
