[moving baked fs discussion to a separate thread. I don't think there's
anything very controversial in here, so it's just nailing down the details]
On 30/09/15 15:20, Martin Lucina wrote:
What do you mean "were it to spit out"? It was a parameter with weird
semantics to rumpbake, no? We don't want rumpbake to spit out anything
except the binary. All we need is an offline "here's a directory, turn it
and its subdirectories into a component" tool/documented command/whatever,
no quirky "add secret files" semantics.
Quoting my original email about baked-in rootfs support:
"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."
I don't see any quirky "add secret files" semantics there. The only
difference (which I'm fine with) is that it should be a separate tool that
spits out a "file system data" component, which you can link in to your
unikernel with rumpbake.
I thought your main complaint was about my implementation, which used
Justin's libuntar and unpacked it into the rootfs, hence my reference to a
linkable component containing a MFS filesystem.
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.
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 ;) ;)
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.
Print a warning if "input" is ridiculously large (>1MB)?
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".
Anything else?
