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

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

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

+1.  I suspect also the dependencies should be shaken (and
mirage-xen-ocaml be the only consumer of openlibm (instead of
mirage-xen-posix)).

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

I always appreciate this! :)

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

+1

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

The motivation was purely CPU cycle based.  GMP and zarith-xen (which
takes esp. on ARM long to compile) depends on bits and pieces from
xen-posix (some headers, and the CFLAGS/LDFLAGS).  It initially depended
on mirage-xen, which depends on cstruct etc., and gets recompiled pretty
often.  After having for a short period some cyclic dependencies (not a
good idea), I ended up with the minimal package (mirage-xen-posix) to
get GMP&zarith compiling.


hannes

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