Re: [MirageOS-devel] towards a common Mirage 'FLOW' signature

[David Scott <scott.dj@xxxxxxxxx>]

Quick update:

mirage-types.1.1.3 has the FLOW signature (with the errors on write that Anil suggested).

vchan.0.9.7 now exports FLOW rather than the old string-y extra-copying interface. Jon: to make this work with cohttp we're going to need some kind of FLOW -> cohttp adapter.

More stuff to think about for v2: the 'shared-memory-ring' code exposes more detail. It's possible to 'read' data without acknowledging it, such that it'll still be there if you crash and restart. This is a bit like TCP retransmitting data you haven't ACKed. We could expose this somewhere. Also, each FLOW probably has some amount of buffering built-into it, for example vchan is limited by the size of the ring set at create time. Perhaps that could be exposed? If a particular FLOW implementation is prepared to allocate buffers it would be good to be able to control that, and apply back pressure etc. Perhaps we could draw some inspiration from somewhere-- JS core's pipes maybe?

Cheers,

Dave

On Mon, Jun 16, 2014 at 10:33 AM, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:

I'm a bit late in the discussion, but:

> * consoles
> * xen inter-domain vchan connections
> * plain TCP
> * (hopefully) TLS connections

For git, we also need in/out channels over the execution of an SSH program execution (ssh <url> git-fetch-pack <args>). I think your change will also allow to do that so that's good :-)

Thomas

--
Dave Scott

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel