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

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



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`





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

 


Rackspace

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