Documentation and guides

Weekly Meeting: 2014-10-14

14th Oct 2014: Vchan, Conduit, library release plans and funky graphs.


Attendees: Amir Chaudhry (chair), Thomas Gazagnaire, David Kaloper, Thomas Leonard, Anil Madhavapeddy, Hannes Mehnert, Richard Mortier, Dave Scott and Gregory Tsipenyuk


Vchan/Conduit code review

Conduit stuff is fairly complex but works in all combinations, (OSX, Linux Unix and on Xen). Some of the code is a bit awkward but the messiness is contained (i.e. it doesn't extend outside conduit). Can establish conduits across domains (some things are untested).

There happens to be an annoying dependency problem. ThomasG notices that you need a tcp stack with vchan but there's a dummy stack in place for this (dummy functors). For now it's easier to functorise over the stack but maybe we don't need a dummy stack, just a dummy ethernet device.

Both ThomasG and Anil aren't happy with current design but it's good to have something (as opposed to nothing)!

mirage-dev releases

The v2 release will freeze v1 (so it will not change) and v2 is the (stable) development release. All the vchan things are in now and stable. Overall, we still need to clean up odds and ends and start cutting releases.

Need someone to set up a cubieboard that will do builds of everything (via cron jobs). Suggestions that we can publish the output to so that it's obvious when things are not working properly.

Anil can only test once back but in the meantime Dave can cut releases — but would like to have a list somewhere to see what should be worked on. Anil mentioned that opam list --depends-on --rec will show what's broken.

Dave will do versioning and checksums on the mirage-dev repo — i.e cut releases on our opam remote to begin with, but not push to the upstream opam remote just yet.


Hannes did the port for no-crypto and TLS and it works on Unix. There are things in XMPP that can be pulled out into separate library and Conduit should be able to help with this.

Also implemented client authentication in TLS which will be useful for startTLS for IMAP (if server supports it). Now have IMAP for Android and maybe on iOS (but that one still has some bugs). Anil has some outstanding change sets to remove certain dependencies (e.g batteries).


TLS on Xen

Hannes recently wrote to Mirage list on where to put the C code (libgp etc) and other small symbols we need. Suggestion from others is perhaps get it working end-to-end without stack protection first. What we don't have is a sense of where to package things up and it's a good idea to have one switch for everything. Concurrent installation keep us honest and reduces the likelihood of errors. This does raises an issue as we share the object files so if we drop stack protection on xen we have to drop it on unix.

Maybe make no-crypto-unix and no-crypto-xen? This was suggested on the list but leads to question of packaging. There will need to be packages for xen and -unix for the whole dependency chain (cross-compilation would be better solution). This might have effects on ctypes.

Irmin Update

ThomasG still removing the dependency on core_kernel. Currently looking at ogit to simply dependencies and then in Irmin. This is fairly straightforward but rather dull and it should be done by the next call (two weeks).


There's been some extensive discussion on the list about tracing (see the repo). Can trace interaction between Lwt threads. Can race unikernels and create graphs. There's a link in the thread and where exceptions have been thrown. At the moment it just numbers threads 1, 2, 3. ThomasG has played with it and it seems very useful.

block read tracing

Mort mentioned that it might be useful to relate mapping between IO and threads as that would help us understand things across unikernels. This is one of the things that Magpis did and he'll will email the list with links to relevant work.

Some questions were raised about the visualisation itself (e.g the white line!) Green line is when one thread resolves and raises another, blue line is when one thread reads value from another. Almost want to see this by module.

ThomasL will write a blog post to help people interpret these diagrams and the next step is to make the whole thing easier to use and make it a separate library. Also pointed out that it was surprisingly difficult to get it to go fast in HTML canvas as changing colours is slow. Ended up having to render this colour by colour.