and developer guides
Attendees: Anil Madhavapeddy, Dave Scott, Euan Harris, Amir Chaudhry, Daniel Bunzli, Vincent Bernardoff, Jon Ludlam, Prashanth Mundkur
Goal is to make the Mirage device driver libraries compile on both UNIX and Xen, so that we can prototype them all in userspace and then just recompile into Xen. All of the required kernel bits in Linux should be there in 3.5 upwards, such as the
evtchn devices. Dave has issued a series of pull requests to make this possible for Mirage Platform, and will merge them this week. This means that
mirage-platform now exposes a xenctrl OCamlfind package.
Anil: we're missing an example to test userspace bits as a simple unit test. Perhaps a simple memory-backed block device would be a useful one to include, as there are significant moving parts required to get it up and running at the moment. Jon: There's some VHD code that we could use and should be in OPAM. Anil: Even a RAM disk would work initially, before this, just to get functional tests running before anything persistent. Dave: tricky thing with blkfront is that the API is different between userspace and kernel mode. Will work on this more with Jon.
Vincent also just finished up the tuntap bindings and is working on migrating
mirage-platform to using it this week.
Anil: Writing up these minutes are a good excuse to regularly rebuild the live
mirage-www with the latest stuff, so he'll try Vincent's patches when they're ready.
Anil and Jon attended the Yahoo hack day. There were giant robots there. They ended up starting OCaml bindings to MatrixSSL.
Jon just writing bindings to it under the UNIX environment but also has stuff working in Mirage. This is a good way of getting SSL support into Mirage as an early stepping stone.
Anil: Lib is GPLv2 so will need to replace at some point but better than OpenSSL for binding. Jon: could we have Dropbox like functionality. using a VM backend as store. Anil: yes, with Async/Cohttp this shouldnt be too hard once userspace drivers are working.
Anil: Hot off the press are some FFI bindings by Jeremy Yallop. Doesn't require any actual C code to bind any more, but still stabilising and perf testing.
Prashanth: Anyone looked at miTLS from MSR/INRIA? Anil: Challenge is to get a verified high-performance version of anything in this space.
Anil started writing a little abstraction library for js_of_ocaml for storage, for eventual integration into Irminsule. It's a bit complicated as you have to write for the case where local storage is present and where it is not. Lib helps take care of that so you don't have to worry when writing your stuff. Need a name for this unified library. Email Anil if you have any ideas! He's going to upload it for next week.
Daniel: Need to do some JS hacking so Anil will send stuff to him too. Also, Anil should check stuff in vg as had to do some similar stuff so check it out and see if there's anything useful in there. Link is here for mli and ml.
Daniel: Bigarray support in Js_of_ocaml?
Anil: JS has typed arrays instead, but I don't know how many browsers support this.
Daniel: Canvas may allow you to use that.
Euan: Everything supports typed arrays except Opera mini (discovered via caniuse.com)
We've set up wg-parallel for (a) multicore and (b) actor thing for stateless programming. Euan is cloning Erlang OTP in Async/Core as his "month off" project. wg-parallel not announced to OCaml list yet until we do some preparatory work.
Euan describes his emerging actor library. Using polymorphic variants as message types. hoping to have type checking between process but running into polymorphism and subtyping issues. Sent some emails to list and apparently can't do it the way he wanted (after chatting with Leo).
Interesting thing is really OTP which is how Erlang builds reliable systems on message passing. Hope that we might build an OCaml runtime that has separate heaps and message passing (of interest to Stephen Dolan and Leo).
Anil: Pipes in Async are abstract: they take alpha/beta values and apply flow-control. The Reader/Writers in Async_unix actually implement TCP. We need a shared memory version. David: API for shared-memory-ring is mostly good, but quite low-level and needs some work to clean it up with accessors. Euan: Hello World in Erlang is program called ping-pong. Haven't benchmarked Erlang's version but OCaml version does 8000 per second. Will start cross-comparisons with Erlang.
Prashanth: For benchmarking, Erlang uses bunch of http stuff.
Euan: In Erlang, they're less concerned about throughput but about handling multiple connections. It's more about scalability of concurrent connections.
Brief discussion about load generation for testing purposes and difficulty of spinning up sufficient load to stress a server. Could use Mirage for better load generators, which would be more widely usable. Anil: May not want to use multiple experimental systems for testing/benchmarking. Maybe the stuff for fuzz-testing might be useful for HTTP though.
wg-parallel list is small at the moment so idea is to start discussion how to move Lwt and Async together. Just need them to work well together as they're both going to be around for a long time. This is a pressing concern from Mirage which has a significant investment in Lwt but needs to migrate to Async in the longer term.
Prashanth: does the actor library consider scheduling to be a concern? Erlang is pre-emptievely scheduled. Can be blocked any time you're running. That's why we need better underlying support in the VM if we want actor model. Anil believes that we can make it work just fine with UNIX processes and message passing and Monitors. The emerging multicore OCaml runtime will help.
Euan: Hot code reloading in Erlang will be more difficult in OCaml. Anil: Sounds like xen live-migration, which everyone says is great but don't really use it. Prashanth: That's one reason why Erlang doesn't have a static type-system (so they can hot-reload). Anil: we should be looking at service-level hot reload, not at the code level (c.f. the ongoing FRP/React discussion).
Prashanth has been looking at OpenFlow versions and seems lots has changed between recent revisions. Some of it breaks backwards compatibility, and semantics too. i.e flow matching has changed between 1.1 and 1.3.
Anil: nothing we're doing requires compatibility with current hardware so perhaps just work with 1.3 and then figure out a backwards compatible mapping. Prashanth: I'll send some links to updated spec (find it here).
No call next week (7th May) as several members are travelling, but we can resume the call as normal in two weeks on the 14th May.