On 29 Jun 2015, at 10:19, Martin Lucina <[email protected]> wrote: > > On Monday, 29.06.2015 at 10:08, Anil Madhavapeddy wrote: >> 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) > > I think Anil and Antti are talking about different things: > > 1) Antti is describing the "setting up a bridge topology > *inside* a rumprun unikernel", and the general problem is "configuring X, Y > and Z in a unikernel", with a view to re-using existing NetBSD > configuration tools for "X, Y and Z" where possible with no changes. > > "X, Y and Z" could be bridge setup, wlan setup, encrypted block volume > setup, etc. etc. Basically anything (applicable to a unikernel) that a UNIX > would do at boot time. > > 2) Anil is describing the "setting up a bridge topology on the *host* > (dom0, unix, whatever) so that a Mirage unikernel can communicate with the > outside world". This is a different problem, and while it is also related > to rumprun, especially for qemu, it is a different discussion :-) > > Am I right?
You're right! I guess the problem with separating them is that the "inside" and "outside" configurations become intertwined with non-trivial topologies fairly soon. Still, reusing existing libraries for internal setups does make sense where possible... -anil
