On Mon, Jun 29, 2015 at 09:04:11AM +0000, Antti Kantee 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? >
I'm almost certain with my rump kernel user hat on I don't want #2 (pass in handcrafted json) because I shouldn't care about internal details. Once that mechanism is live you carry the burden of supporting it forever (well, as least for quite some time until you're sure nobody uses that anymore). (I'm on vacation now so I'm not very responsive with emails. Sorry.) Wei. > - antti
