implementation selection

[hannesm]

KV is the canonical example that has a variety of implementations we'd like to support:

• kv-mem
• kv-unix (-t unix only)
• kv-dns (NYI)
• kv-git
• kv-fat (atm via fs bridge)
• crunch (RO)

in MirageOS atm the unikernel developer has to select which implementation should be used, which is wrong. instead, for any unikernel with such a KV device (KEYS : KV_RO), noconfig should offer an optional --kv-keys=[mem|unix|dns|git|fat|crunch] (no crunch if KV_RW) and emit the necessary boilerplate (including boot parameters etc.).

[hannesm]

taking a step back, maybe it helps to document what the current state of things is:

• (1) we define a mirage-interface (e.g. Mirage_kv.RW), which is programmed against in a unikernel
• (2) functoria allows to define type rw = RW and let rw = Type RW in mirage_impl_kv.ml
• (3) each kv_rw implementation that is selectable is defined in mirage_impl_kv as well:
  • (a) dependencies (e.g. pclock) / type (used to generate the functor application) method ty = pclock @-> rw
  • (b) boot arguments (maybe configuration time rather than boot time) -- e.g. which directory to use for mirage-kv-unix
  • (c) opam package implementation e.g. method packages = Key.pure [ package ~min:"1.2.3" "mirage-kv-unix" ]
  • (d) module name Mirage_kv_unix
  • (e) connect function (receiving the module_name and values for its dependencies, outputting OCaml code for main.ml -- usually %s.connect () modname -- but can of course be more complex)
• (4) a direct_kv_rw function (string -> rw Functoria.impl) -- used in various config.ml -- which depending on the target (-t yyy) selects the default implementation (this is not present atm, but there's a direct_kv_ro -- think of an analogous one for rw)

[cfcs]

We discussed storing the information what devices are available/implements which interfaces in OPAM metadata to make the information available without having to hardcode it in noconfig or mirage. This will allow library authors to self-declare, which should make it more ergonomic to develop against.

It will allow noconfig to display a list of implementations for the user to choose from.

Concretely, for device implementations we will need:

• Which device type it implements, e.g. kv-ro or Mirage_kv.RO (unclear if this should be a pet name or the name of a specific type or signature -- if we do that, maybe need to refer to opam package where that can be found?)
• Which ocamlfind/findlib packages should be linked in order to build, e.g. mirage-kv-unix or tls.mirage
• Which functor (provided by the findlib packages) instantiates the implementation, e.g Tcpip_stack_direct
• Which targets (unix, spt, hvt, genode, etc) this implementation works on. Maybe we can use the OPAM constraint syntax for this.
• Optionally a flag to describe this as a "good default" for the supported targets. Maybe this should be per-target. If two relevant packages declare themselves as "good default" we have a problem, in this case we should let the user choose.
• Maybe a short description that noconfig can display, like "the crunch target will embed the files inside the unikernel image at compile-time"

We discussed encoding this either into OPAM feature keys, or keys prefixed with x- (which we think are available).

[cfcs]

(continued): Some of these fields can under various circumstances be inferred, that would be nice to bring down the amount of boilerplate device implementers have to write.

[hannesm]

in respect to the name, I'd suggest to use the interface name -- Mirage_kv.RO -- since in the end that's what we're working on anyways ;) -- note that the opam dependency is already defined in the opam file (i.e. that it'll need the mirage-kv package), so we don't need that one.

potential examples follow:

• x-mirage-implements: "Mirage_net.S:Netif" {target = "solo5"} for mirage-net-solo5
• x-mirage-implements: "Mirage_net.S:Netif" {target = "unix"} for mirage-net-unix
• x-mirage-implements: "Mirage_stack.V4:Tcpip_stack_socket.Make:stack-socket" {target = "unix"} for tcpip
• x-mirage-implements: "Mirage_stack.V4:Tcpip_stack_direct.Make:stack-direct" for tcpip
• x-mirage-implements: "Mirage_protocols.TCP:Flow.Make:tcp" for tcpip

certainly, the interface name could be part of the key (if that eases opam queries): x-mirage-implements-mirage-net-s (TODO figure out what are the allowed characters in keys)