[MirageOS-devel] Structure of mirage-platform for Solo5

[Martin Lucina <martin@xxxxxxxxxx>]

Hi,

Together with Dan Williams we're working on getting the Mirage/Solo5
bindings into mergeable state. Part of this process is figuring out what
the structure for mirage-solo5 (the "platform bindings") and its
dependencies should be.

The current structure of mirage-platform for Xen (the only non-UNIX target)
looks like this, in dependency order with leaf packages omitted:

minios-xen: Mini-OS kernel
  mirage-xen-minios: Openlibm interfaces needed by OCaml runtime
    mirage-xen-posix: libc and POSIX interfaces needed by OCaml runtime
      mirage-xen-ocaml: OCaml (asmrun) runtime
        mirage-xen: Mirage/Xen platform bindings

For Solo5, we'd like to simplify the structure to something like this:

solo5-kernel-XXX: Solo5 kernel with no POSIXy/libc interfaces
  solo5-ocaml-runtime: OCaml runtime and all libs it needs to run on Solo5
    mirage-solo5: Mirage/Solo5 platform bindings

The "XXX" in the solo5-kernel package refers to the different Solo5 targets
(virtio/qemu and ukvm).

solo5-ocaml-runtime is essentially a roll-up of mirage-xen-minios (which is
just another name for Openlibm), mirage-xen-posix and mirage-xen-ocaml into
a single package.

The rationale behind this structure is threefold:

1) It has explicit contracts defining which interfaces each layer
provides/depends on. Further, by not providing a separate "posix" package,
we discourage adding more C code to support "random bits of POSIX native
library X might need" which encourages the use of pure-OCaml libraries in
Mirage.

2) I don't see a need for other OPAM packages to consume the posix and
openlibm interfaces separately. These exist only to support the
freestanding OCaml runtime. There's nothing Mirage-specific in this
package, it is a freestanding build of asmrun on Solo5 interfaces, hence
the name solo5-ocaml-runtime rather than mirage-solo5-ocaml.

3) I would eventually like to produce a "retargetable" freestanding OCaml
runtime which would be shared by the Xen, Solo5 and other future non-UNIX
targets. However, the first step is to get Solo5 upstreamed.

Thoughts? Are there any showstoppers with the proposed structure?  Is there
a reason I've missed for the xen-ocaml / xen-posix split in
mirage-platform?

Martin

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