and developer guides
Attendees: Amir Chaudhry (chair), Thomas Gazagnaire, David Kaloper, Thomas Leonard, Anil Madhavapeddy, Hannes Mehnert, Richard Mortier, Dave Scott and Gregory Tsipenyuk
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)!
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 doesmiragework.com 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
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).
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.
no-crypto-xen? This was suggested on the
list but leads to question of packaging. There will need to be packages for
-unix for the whole dependency chain (cross-compilation would be
better solution). This might have effects on ctypes.
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
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.
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.
TLS and conduit discussion - Worth looking at TLS/Conduit stuff and Hannes can take a look once Anil has pushed his code.
Amir will add a regular agenda item to review the previous call's notes. Depending on the content of each call, he may also keep a list of actions for reviewing next time.
Next call is scheduled for 28th October - Please refer to the mailing list for actual details a day or so in advance.