On Monday, 29.06.2015 at 10:08, Anil Madhavapeddy wrote:
On 29 Jun 2015, at 10:04, Antti Kantee <pooka@xxxxxx> wrote:
Hi,
So I was thinking about the problem of specifying a network bridge
configuration in rumprun, as motivated here:
http://wiki.xenproject.org/wiki/Upstream_QEMU_stubdom
It was easy enough to add bridge manipulation to netconfig, but that
doesn't really help us with specifying the configuration at lauchtime.
Assuming we want to avoid rumpctrl for the "more moving parts" reason,
there are, as far as I can see, two approaches (not really specific to
bridge configuration, so imagine it's a general problem):
1) improve "multiexecutable" support to allow for "barriers", i.e. wait for
all programs [..n-1] to finish before starting to run [n...]. Then bridge
configuration becomes someone else's problem.
2) add support to rumpconfig to be able to specify bridge config via json
For "1", the hard part is the syntax towards the user. Solving the problem
of passing a different argv[] to each "executable" within the unikernel is
probably close enough so that it should be solved at the same time, and the
whole simple matter unravels into a mess of solving everything.
For "2", it doesn't sound feasible to add support to the rumprun command
line syntax. Therefore, we'd have to add support for passing blocks of
handcrafted json. Do we want to go there? If yes, should the custom
blocks be handled by the monolithic rumpconfig, or should there be some
mechanism of linking in components which do their own json parsing, and
simply sending the custom blocks off to custom parsers? Support for custom
json handlers probably in the order of 25 lines of code, but what does it
do for user-perceived complexity?
I'm (almost) certain we'll need "1" sooner or later. I'm not (entirely)
convinced we'll need "2". Thoughts?
Bridge configuration is suitably varied that replicating the details is
almost always infeasible. We do 1) in Mirage, and you can retain low latency
setup by writing a handcrafted binary that calls the bridge ioctls directly
and avoids shell script forking.
The other benefit of just doing 1) sooner rather than later is that it will
permit other forms of setup in the future such as vchan channels for enclaves
of unikernels (e.g. miragetls+php+nginx)
