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

Re: [MirageOS-devel] conduit + vchan

Hi Dave,

The conduit merge required quite a few different patches across repositories, so I've opened up an OPAM remote to track all the branches required here: https://github.com/mirage/mirage-dev

There's a Travis file to check that the overall set of packages are working.  Since it's a sequence of git remotes, we'll need to occasionally push dummy commits to the mirage-dev repository to trigger a recompile with the latest sub-repositories.

I'm tracking the overall feature in : https://github.com/mirage/mirage/issues/287

So far, the Conduit API is settling down and works with Lwt_unix, Async and Mirage, including client DNS lookups and HTTP requests.  Before merging, I'd like to:

- add sexp accessor functions
- switch to V2 interfaces (required for previous)
- get OCaml TLS hooked in

Once this is all done, Conduit can be released independently of the rest of the Mirage libs (which in turn unblocks a Cohttp 1.0 release).  I'm just holding back releasing it too early so that we don't have to keep revving the Lwt_unix interfaces all the time.

Regarding vchan, the biggest difference in the new APIs is that Conduit creates a V1_FLOW interface that abstracts across all the connection mechanisms (currently TCPv4 and vchan).  Previously in Mirage 1.0, this was hardcoded to TCPv4, and I've had to modify those interfaces in the development repository to bring TCPv4 in compliance with the FLOW interface (it's slightly odd that we didn't do that before!).


On 23 Aug 2014, at 00:43, David Scott <scott.dj@xxxxxxxxx> wrote:

In the last weekly call I agreed to work on conduit + vchan.

Looking at the Lwt_unix conduit API


It seems to be using Lwt_io input/output channels. So my plan is to implement Lwt_io channels on top of the FLOW exposed by vchan. I've got a prototype of that here:

Does this general approach seem sensible? Since the conduit code is quite new and under heavy development I thought I'd better ask :-)

A side-benefit is that Lwt_unix apps which use vchan can decide to use either the Mirage FLOW interface or the Lwt_io interface.

It looks like the Mirage conduit interface is FLOW based, so I can expose the existing vchan implementation there.

Dave Scott
MirageOS-devel mailing list

MirageOS-devel mailing list



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