future of mirage-platform

[hannesm]

during a discussion between @reynir @mato @yomimono we decided for a way forward with this repository:

• split unix parts into mirage-unix
• split xen parts into mirage-xen
• superseed the remaining bits by ocaml-freestanding

the transcript of our meeting follows:

packages:
minios-xen (just the minios.o + package config stuff for linker flags)
(no external depenencies)
ocaml-freestanding, replacing mirage-xen-posix, mirage-xen-ocaml,
mirage-xen-minios
then we'll have mirage-xen and mirage-unix in mirage-platform (and can
move them to separate repositories)

build systems in mirage-platform could be moved to topkg/ocamlbuild (we
can copy mirage-solo5's setup for this)

needs to be some sysdeps_minios.c (like sysdeps_solo5.c) which includes
a console write (for printf and stdio) and exit, abort, gettimeofday,
times. now that there's no malloc in solo5, that's where sbrk and
malloc are. in the minios case, we need to provide some sbrk type thing
that can talk to minios's page allocator.

upstream minios doesn't namespace symbols, fixable with objcopy stuff
(and we might be able to upstream if we hide it behind a conf option),
but need to clean up the headers which is annoying. why do we care
about the namespacing of minios? we care because there might be conflict
with ocaml-freestanding (although we're not sure without trying it). we
could do a hack for sysdeps_minios where we include only minios headers,
and repeat any declarations that are internal to ocaml-freestanding, or
something like that

gmp and zarith are the ony things with native code that will have this
problem. if we do this, zarith-xen and gmp-xen will go away, but we need
to get them to compile, which is a matter of massaging pkgconfig

how much c code do we still have in mirage-xen that uses some specific
minios interface? that's the only code that needs to live both in
ocaml-freestanding and mirage-xen (IIUC)

homes of stubs: ocaml-cstruct & such have stubs both in solo5 and in
repositories like cstruct, which is strange; we would like to have that
cross-compiling only at a single point. hannes has changed his mind from
putting them in separate packages to into the backend repo

net and block stubs in solo5 will move from mirage-solo5 to
mirage-net-solo5 etc

where are those hooks in the xen side? it's a bit unclear, they are kind
of all over the place.

we might not need any of these changes for x86, but we don't want to
retire arm (although we can ignore it for now, maybe?)

(go through commit messages, mato thinks we might need like 10 of them
but maybe we can just start with upstream minios, see what's really
needed and put it back in)

it's unclear how our stuff interacts with the minios thread scheduler -
probably originally it did but now maybe not

so out of the stubs in mirage-platform/bindings (which will end up in
mirage-xen, with the dead code thrown out). from mirage-platform
xen-ocaml goes away, xen-posix goes away. there is stuff in xen, it
mirrors what's in mirage-solo5, including the magic which we'll still need

bindings -> mirage-xen/lib/mirage-bindings, mirage-xen -> mirage-xen/lib

hannes is willing to pull the mirage-xen and mirage-unix stuff into its
own repositories without making major changes

looking at dependencies for mirage-unix, shared-memory-ring "has stubs
but only barrier stubs", those should go into mirage-xen

martin is willing to do this, mindy also willing to learn a bunch of
stuff and try it in may if not already fixed by someone more familiar
with this area

[avsm]

also a pointer to unikraft, which is the "new" minios from xen which is easier to integrate. we could look into adding ocaml-freestanding as a package there.. http://xenbits.xen.org/gitweb/?p=unikraft/unikraft.git

[hannesm]

The new path is ocaml-freestanding and solo5 support for Xen PVH, as discussed in mirage/mirage#1159. closing this issue, and archiving this repository.