Re: [MirageOS-devel] Mirage/Solo5: What to do about C stubs?

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Hi Martin,

On 19/07/2016 17:47, Martin Lucina wrote:
> the mirage-solo5 package (i.e. the Solo5 "platform bindings") currently
> bundle C stubs for unrelated packages which get linked into a
> libsolo5camlbindings.a.
> 
> Based on some discussion on Slack and also ongoing in a PR Mindy pointed me
> to (https://github.com/mirage/io-page/pull/34), is the general plan to move
> as much C stubs as possible directly into the packages that actually use
> them?

This is the general plan (see also
https://github.com/mirage/mirage-platform/issues/124).  It would IMHO be
nice if this would be done within the 3.0 release cycle, just to be able
to declare simple and clean constraints (conflicts: [ mirage-xen <=
3.0.0 ] etc.).

> If so, I have a bunch of work ahead of me and will need to postpone
> releasing Mirage/Solo5 to opam.ocaml.org until this is complete, since if I
> release what we have now then cleaning this up afterwards will be very
> painful.

What is the way forward?  Seemless integration of solo5 won't happen
before mirage-3.0 anyways.  But there is value in having the solo5 parts
upstreamed (into opam-repository and the mirage tool) soon (so people
can more easily play around with it).  The removal of the C stubs in
mirage-platform/mirage-solo5 should not be entirely on your plate (atm
I'm investigating topkg+clib+xen_linkopts [see
https://github.com/mirage/mirage-entropy/pull/28], since the oasis and
postconf.sh/postconf.ml way is rather inconvenient).

I'd think first merge solo5, then move to topkg, then move the cstubs
into the respective libraries.

> The following is an inventory of C stubs we've "accumulated" in
> mirage-solo5 so far:

Thanks for that extensive list!


hannes

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