Mirage OS Logo

The MirageOS Documentation

and developer guides

Weekly Meeting: 2014-11-12
By Amir Chaudhry - 2014-11-12


  • Review previous notes
  • mirage-dev releases (and future thereof)
  • TLS integration into conduit
  • IPv6 patchset
  • Xenstore TNG
  • 4.02 support
  • mirage-vagrant-vms
  • mirage-profile status
  • Preliminary thoughts for 3.0

Attendees: Amir Chaudhry (chair), Thomas Gazagnaire, Thomas Leonard, Jon Ludlam, Anil Madhavapeddy, Hannes Mehnert, Richard Mortier, Nicolas Ojeda Bar, Mindy Preston, Dave Scott, Magnus Skjegstad and Nik Sultana


Future of mirage-dev

Releases are done! Yay!

Have yet to update the website to remove the refs to mirage-dev in the installation instructions. It would be great if someone could do this.

TLS integration into conduit

Not keen to fix lwt-ssl bindings. Would be keen to get people to use TLS stack and it would be good to have environment variable to switch between stacks. Perhaps import it in now but not as the default and later make it the default.

We should begin serving the site over https using the unix backend (Mirage doesn't serve https yet). Actually, we should merge in the IPv6 stack and then serve that. For example we could start doing this with one of our live deployments and then roll it out elsewhere e.g start with blobs.openmirage.org

Can continue the thread on the conduit repo and Hannes is welcome to add more debugging etc to conduit.

IPv6 patchset

Nicolas been working on this and it touches many different parts of Mirage. There's an RFC and discussion thread for those who wish to keep up.

Nicolas is current modifying the V2 types of Mirage and Dave says we could use both but have to pick one from within. It's not clear to people how we use V1 and V2. V1 became stable with the Mirage 2.0.0 release so V2 is now the development version. In other words, for stable users we want V1 to be used and for developers we want to use the V2 interface. This will need some clarification to avoid confusion.

Want to fix networking in the next release and are thinking of getting rid of the StackV4 interface entirely.

For now, Nicolas can sync V1 and V2 in Mirage and get a release and anything modified is in V2, then we can set a flag for dev versions. It's worth noting that in OPAM 1.2 we can select specific versions of packages with constraints on the command line (e.g opam install mirage > 2.0.0).

Xenstore TNG

[TNG → The Next Generation -- in case you were as confused as I was. AC]

New version of Xenstore is coming that includes the work James Bielman did on adding Mandatory Access Control (MAC). Also want to improve the client interface and version control using Irmin. Some of the changes will be disruptive but we can take care over this.

It would be useful to have a functor to xenstore (i.e an abstract way to read/write, which we can use in conduit and Jitsu etc). In addition, the UI needs improvement as using it feels like ping pong.

4.02.1 support

Mirage currently only works on 4.01.0 but the latest OCaml compiler version is 4.02.1, (released in October). There are a number of improvements we can benefit from so we should work on this.

Anil has already made a start on it but may want to hold off due to the number of outstanding patch reviews. Supporting 4.02.1 means porting the OCaml runtime out as a separate C-lib. This can then benefit from opam constraints (i.e pull down the appropriate runtime based on the compiler). We've done this well for miniOS and the ocaml-dev team would also be interested in this approach.

This is probably about a week's worth of work and if anyone has time to look at it, please do email the list. It would also be good to be benchmarking this at some point.


This has worked worked for Dave and Mort. The plan is to have it running for testing and then also be able to add other IDEs etc. If anyone wants to look at vagrant clouds and go from code to binaries, that would be quite useful. We would have to host the binaries, which is fine as we do that currently. We just need to provide a URL, description and some metadata and can point back to blobs. Can advertise the vagrant thing at an upcoming conference (operatingsystems.io). The repo is at mirage/mirage-vagrant-vms.

Jon uses the vagrant cloud a lot but has not looked at Mirage yet. Has boxes of XenServer if anyone wants to try those. Also has scripts that automatically update version numbers and can share this with Nik.

mirage-profile status

ThomasL sent a message to list with a status update. It's now in mirage-dev but there is nothing depending on it. Will send PRs to platform, TCPIP and so on. Mindy is trying out some tracing at the moment. Also looking at GC and there may be some stuff to upstream as it may be helpful to know when GC starts and how long it lasts. At the moment just checks with registered callback so doesn't change OCaml interface.

Preliminary thoughts for 3.0

Amir is keen that we start getting ideas down for what Mirage 3.0 will look like and start working our way towards it. Would prefer that we time things well so that libs can be upstreamed to opam proper at the same time we announce (i.e not have things in dev or that require pins).

Thoughts include a working Javascript backend, can have things working with iOS and Android at that point. Could consider this the 'multiscale release' as we're setting ourselves up to be able to work with multiple backends. Amir will bring up this agenda point every few calls to see where thoughts are.



  • Library request! ThomasG and Anil have built ez versions of Daniel Bunzli's libs, such as ezxmlm and ezjsonm, which are less flexible but provide more convenient functions. They'd like to have an ezcmdliner, which takes notions of terms and does unix.get-env. It would let them replace adhoc environment parsing in configuration and let them assemble an environment. One of the interpretations would be a dialog-based interface and could do bash-shell completion. This way, mirage configure can drop you into a UI to select the things you wanted. It should be a simple library and only a couple of days work as it's just a front end to cmdliner itself. After some discussion, it seems that Dave might have pieces of this so he'll dig it out and have a look but others are very welcome to dive in.

  • Change of call day: After some brief discussion, it seems that Wednesday is actually better for most people so we'll switch the call day accordingly. Same time, different day.

  • With the above change of day in mind, the next call is scheduled for Wednesday, 10th December - Please refer to the mailing list for actual details a day or so in advance.