Re: [MirageOS-devel] [RFC/PULL]: Rumprun configuration specification and rototill

[Martin Lucina <martin@xxxxxxxxxx>]

On Monday, 04.01.2016 at 12:27, Anil Madhavapeddy wrote:
> On 4 Jan 2016, at 12:15, Martin Lucina <martin@xxxxxxxxxx> wrote:
> > 
> > If I have a Mirage/Rumprun hybrid unikernel (whether using -k or not,
> > irrelevant) and I would like Rumprun to mount some block devices, but
> > Mirage to handle the network stack, can I express this using a single
> > JSON configuration?
> > 
> > I've not thought about this enough, but it would seem to imply that Rumprun
> > config would handle "fs", but not "net", which would be passed to Mirage
> > somehow. A strawman of how this could work:
> > 
> > 1) We would need to specify the method that rumprun uses to pass the
> > configuration on to the application. This could be as simple as writing it
> > out to "/config.json".
> > 
> > 2) In a hybrid unikernel as described above, presumably -lrumpnet_netinet
> > and -lrumpnet_netinet6 would not be linked in. This would have to be
> > exposed to config.c somehow (through a data structure with a list of
> > baked-in components at rumprun-bake time?), and on this basis (no netinet),
> > config.c would not handle those parts of the configuration.
> > 
> > I may be completely off on the wrong track here -- would appreciate input
> > from the Mirage (and other?) unikernel folks on this list. This would also
> > be a good discussion to have on the "cross-project" unikernel.org once the
> > discourse.org setup there is complete.
> 
> It sounds to me like this is a map function over the configuration: you
> want to pass the JSON tree to a function that descends over the various
> nodes that convert the configuration into a concrete (device_tree,linker)
> tuple.
> 
> The output of this could then grabbed by the linker or domain builder in
> order to satisfy their particular jobs.  Bear in mind that Mirage or
> HalVM may also want their own linking flags that are OCaml- or Haskell-
> specific as well.
> 
> So if Mirage provided a set of command-line binaries that accepted
> a JSON configuration fragment for just the network and storage setup,
> and rumprun have the ability to shell out to them to delegate a portion
> of the configuration, that might be a nice way to glue different toolchains
> together...?
> 
> (Assuming I've understood rumprun's role in this correctly as the main
> entrypoint command).

That [rumprun's role as main entrypoint command, which also happens to do
config parsing and application] is currently correct.  However, in the case
of hybrid Rump/X unikernels, and indeed also in the case of gorump or other
future users of kernonly mode I'm not convinced that there should be a
(rumprun-provided) configuration parser/executor at all.

If there is a "main entrypoint", akin to a "/sbin/init", which is
responsible for parsing and applying the configuration, then it becomes
hard to delegate parts of that configuration to other layers.
Conceptually, as you wrote, it is just a map function. However that map
function would need to know:

  a) Which components are present in the unikernel as a whole.
  b) Which of those components are to be configured by the (rumprun-provided) 
config layer.
  c) Which of those components are to be configured by the (from rumprun's
  PoV) application layers.
  d) We would also need to define an interface for c).

Thinking about it, this means we have the layering wrong. It seems to me
that we need an extra split:

  1) A config library with a C API to apply the various bits of
  configuration.
  2) The configuration parser / "main entrypoint" which is a client of 1).

Now, rumprun unikernels which run full libc applications get 1) and 2),
i.e. more or less what we have today.

In the case of kernonly/Mirage/other hybrids, it would be the
responsibility of the (non-rumprun-provided) "main entrypoint") to provide
a 2) compliant with the spec and call out to 1) for those rump kernel
components it wants to configure.

Thoughts? I realise this is a bit handwavy, but it's the best idea I have
so far.
 

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel