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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 19 May 2016 at 11:00, Martin Lucina <martin@xxxxxxxxxx> wrote:
> 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.

Yes mirage-xen-minios should probably be renamed. Originally it
included minios-xen too, but when minios-xen added opam support
directly that wasn't needed any longer.

> 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?

It all sounds fine to me. I don't know why we have the current split.
It happened in this PR:

  https://github.com/mirage/mirage-platform/pull/125

However, there is no description in the PR nor anything in the commits
explaining why the changes were made. Perhaps Hannes or ThomasG can
say more.


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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