Re: [MirageOS-devel] sexplib v0.9.0 breakage of MirageOS unikernels (xen & solo5)

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 23 Mar 2017, at 13:30, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 
> On 23 Mar 2017, at 12:41, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>> 
>> Hello,
>> 
>> sexplib v0.9.0 was released to opam-repository.  This is a successor of
>> 113.33.03.  Since v0.9.0, it now depends on base, a new standard library
>> replacement by Jane Street (a stripped down version of Core).
>> Base contains C code, which is not cross-compiled to xen/freestanding
>> targets, thus we end up in undefined symbols (see
>> https://github.com/mirage/mirage-www/issues/547).
>> 
>> I'm not sure what the way forward is here -- the current opam-repository
>> doesn't let anyone build any MirageOS unikernels which depend on (uri,
>> cstruct, vchan, tls, x509, mirage-net-xen, ..) unless pinning sexplib to
>> 113.33.03 ("opam pin add sexplib 113.33.03" should do the trick).
>> 
>> I would be interested what other people think about depending on base -
>> I personally think it still is a huge library (base.cma is ~5MB), and
>> thus in stark contrast of the goals of MirageOS (once LTO and other
>> things are in place, this may reduce the 5MB to less) - which is minimal
>> virtual machine images.  Also, base seems to be a collection of several
>> things, whereas there are other minimal high quality libraries available
>> (e.g. astring).
>> 
>> So, how should we move forward here?  My current favourite is 3 or 4.
>> (1) split universe, constrain to sexplib <= 113.33
>> (2) adapt base to freestanding&xen
>> (3) re-develop a dependency-free sexplib
>> (4) get rid of sexplib converters
> 
> We could also ask the Sexplib maintainers if the Base dependency is a
> hard one.  I'm CCing Jeremie Dimino -- is it possible to relax this for
> Sexplib so that it can be as dependency-free as previous versions are?
> 
> I don't think a hard Base dependency is practical right now -- we do
> need some time to evaluate it and to check how it interacts with LTO.
> It is promising since it uses module aliases throughout, but we haven't
> tested it at all in this regard.

A followup on this after an offline discussion with Jeremie -- there
are some efforts ongoing to reduce Base further, but they will 
of course take time and won't happen immediately.  So it cannot be a
core dependency on a Mirage hello world.

Sexplib has a long and storied history [1] and was one of the first
syntax-driven serialisers, and so has lots of gnarly edges as it has
evolved over the years to support many usecases.  It is unlikely to 
get more lightweight itself, and Jane Street themselves have a more
lightweight replacement: https://github.com/janestreet/parsexp

This all points to the general agreement that we should drop support
for sexplib in core libraries.  Daniel's library seems like a fine
replacement, but in the short-term, will anything go really wrong if
we just remove the sexp serialisers?  They don't seem to be a critical
part of the interface, and we could also just define Fmt-printers for
the purposes of debugging.  When we introduced the sexp serialises, we
didn't have Fmt to provide a usable interface to Format, but we do now...

My thanks to Jeremie for all his help with maintaining Sexplib
throughout the years. It was a very helpful library when we had no
other way to print out arbitrary OCaml types.  I seem to remember a Mirage2
release panic when Sexplib introduced an accidental dependency on Unix,
and a rapid fire release upstream to fix our issue and not delay that
release :-)

My apologies for not spotting the Base dependency when merging this
new release into OPAM, as it was not of course included in the revdeps
tests.  I hope to have acceptance tests (such as actually compiling a
Mirage unikernel) in the CI in the future as part of per-merge tests
for big releases like this.

[1] 2005 release announcement: 
http://caml.inria.fr/pub/ml-archives/caml-list/2005/11/1de402d6222041aeebe6120cc75bf1d2.en.html

regards,
Anil


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