Hi, On Sat, Oct 17, 2015 at 11:58 AM, Rupert Horlick <[email protected]> wrote:
> Hi all, > > I am currently working on building a functor which takes a V1.BLOCK > implementation and creates a new BLOCK implementation, with ORAM > capabilities. > > I’ve been looking through the APIs and I had a couple of questions about > the structure of things: > > > 1. Is there any specific reason why mirage-block-unix > <https://github.com/mirage/mirage-block-unix/blob/master/lib/block.mli#L19> > and mirage-block-xen > > <https://github.com/mirage/mirage-block-xen/blob/master/lib/blkfront.mli#L16> > both > implement V1.BLOCK and add types themselves, rather than implementing > V1.BLOCK_LWT? > > No reason at all that I can see or think of. We should probably use `V1_LWT.BLOCK` to simplify things (a little). > > 1. Both implementations have a “connect" method of type "string -> [`Ok > of t | `Error of error] io”, is there a reason why this is not part of > the BLOCK signature? It would be nice to be able to rely on the > implementation having this method. > > Ah, this is on purpose. IIRC there are 2 reasons: 1. we wanted to allow implementations to use types other than strings https://github.com/mirage/mirage-block-volume/blob/354ba1697f564380ff5637517f77b5931eabdb16/lib/vg.mli#L113 https://github.com/mirage/mirage-block-volume/blob/354ba1697f564380ff5637517f77b5931eabdb16/lib/vg.ml#L347 We could have used something like a URI and parsed it in `connect`, but since we're doing as much as we can statically it seems nicer to be able to use types like records. 2. we wanted to "hide" the raw connection creation functions as much as possible, so we could be sure that code that operated over a `BLOCK` (say formatting a disk partition) didn't re-`connect` and start writing to an unexpected part of the disk. Cheers, Dave > It would be great to clarify these points before I move ahead with the > implementation. > > Thanks, > > Rupert > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > -- Dave Scott
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
