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

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

Hi,

On 13 Jun 2014, at 11:26, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

> 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?

That’s a good point — I can certainly imagine a hard error being reported 
(something like ECONNRESET?)

How about this for a plan:

1. I’ll make a pull request for types V1 to add a FLOW, with errors on writes, 
which isn’t used anywhere and so shouldn’t break anything (unless the name FLOW 
shadows some other signature)

2. I’ll start making a list of API breaking changes we want to make for V2, 
including using FLOW everywhere (which means modifying all the write() 
functions). Perhaps I’ll start writing a V2 module?


> 
>> 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.

Great.

Cheers,
Dave

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


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