[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Hannes Mehnert <hannes@xxxxxxxxxxx>, Jeremie Dimino <jdimino@xxxxxxxxxxxxxx>
  • From: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • Date: Thu, 23 Mar 2017 13:30:55 +0000
  • Cc: mirageos-devel <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 23 Mar 2017 13:31:04 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=recoil.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=koPQiBWLHtUAwz1MQhrkm8NUK8ImFlE+LafoPWLZtxE55smL3+t DIqCNTZ5M8liazNzTFqp66AK4PrI4R/UMDoOxACQtwt9PAHoveyRgUYQgrpCnSpK d6GQE/d/STZ7PfjsFZK+FY9uvlL4W1FDSEI/EBbX0lqSct6ifby1EPwE=
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

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.


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.