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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 12 Jun 2014, at 21:38, David Scott <scott.dj@xxxxxxxxx> wrote:

Hi,

I'd like to create a common Mirage 'FLOW' signature to represent reading and writing along some kind of 'connection'. I think we could satisfy the signature in multiple places including at least

* consoles

* xen inter-domain vchan connections

* plain TCP

* (hopefully) TLS connections

It would be nice to write clients and servers which would work over multiple FLOW implementations.

For discussion I've extracted the 'FLOW' from 'TCPv4' to show you what it would look like:

https://github.com/djs55/mirage/commit/87f9855f22f997264870f903c998b1d92186fdef

In V2 of the API I'd like to turn the CONSOLE signature into a combination of DEVICE and FLOW.

This looks good to me.  The one caveat is why write cannot return an error in the existing API.  It is possible for the lower-level transport to signal a hard error, although we rarely do so at the moment.  In the interests of future compatibility, should we make that change?

I notice the low-level network APIs (NETWORK, ETHIF, ...) are *almost* like this except they have a function like

val listen: t -> udp:callback -> tcp:callback -> ... 

Perhaps later (V2, V3?) we could split this into something like a 

val read: t -> buffer (* satisfy FLOW *)

val classify: buffer -> [ `UDP; `TCP ]

-- is that a good idea?

I don't think the listen function should be in the FLOW signature at all, since this is part of the resolver API that establishes connections.

This is compatible with your patch, since the network APIs can "include FLOW" and define the additional connection-specific functions without issue.

cheers,

Anil

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