Re: [MirageOS-devel] mirageos 3.0 : let's break some APIs

[David Scott <scott.dj@xxxxxxxxx>]

(sorry I hit send too soon!)

On Sun, Jun 5, 2016 at 2:45 PM, David Scott <scott.dj@xxxxxxxxx> wrote:

Hi,

On Wed, May 18, 2016 at 5:28 PM, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:

...

I'm surely missing many things folks would want to incorporate in a big API-breaking release -- please do let us know what they are. :)

I'd like to address some problems with `FLOW`, in particular:

- the `read` function

val read: flow -> [`Ok of buffer | `Eof | `Error of error ] io

returns a fresh arbitrarily-sized buffer, which is inconvenient when unmarshalling data of known size. For example in ocaml-9p https://github.com/mirage/ocaml-9p/blob/cb9f5a6c83051ac5dfa7fc7a43ca6a2910a0a241/unix/flow_lwt_unix.ml#L50 we constantly allocate buffers of size 1k and read as many bytes as are available, even though at the higher-level the messages are preceded by fixed-size headers containing payload lengths. It would be better if the 9P client could have a single per-connection read and write buffer with length set to the dynamically-negotiated message size and then use a new function

val read_info: flow -> buffer -> [ `Ok of unit | `Eof | `Error of error ] io

This would make `FLOW` more similar to `BLOCK`

and a second problem I have with `FLOW` :) is over close. `close` is defined as performing a flush and signalling that no more writes will happen, like `Unix.shutdown`. I think this is fine, and it matches what the TCP/IP stack is doing. I think we're missing a `disconnect` which would get rid of all connection state, like `Unix.close`. In other places we have `disconnect` by virtue of `include DEVICE`. I think we should add the missing `disconnect`.

Anyway, sorry for 2 emails where 1 would have done, let me know what you think!

Cheers,

Dave

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