On 29 Jun 2015, at 10:04, Antti Kantee <[email protected]> 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) -anil
