On 14/10/15 14:23, Martin Lucina wrote:
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.
What is it with this subject and a full throttle obsession for multiple
incompatible ways to do things?
If it's supernecessary to be able to specify additional components on
the command line -- I'm not currently convinced either way -- let's do
it via a switch which takes the bake.conf syntax as an inline argument.
That way people who might want to remove something don't get screwed.
Even without the unusability problem, I wouldn't just toss "system" and
"application" objects into the same pile, like the above proposal does,
without very very careful thought.
For now, let's do nothing. There's no substitute for a week or two of
actual use experience for deciding if we even need a *convenience* feature.
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.
Agree.
Not sure I'd prevent from mounting it as root, though. However, a big
fat warning may be in order.
