Xen project Mailing List

Hi,

On Sat, Oct 17, 2015 at 11:58 AM, Rupert Horlick <rh572@xxxxxxxxx> 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:

Is there any specific reason whyÂmirage-block-unixÂandÂmirage-block-xenÂ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).

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
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Dave Scott

Re: [MirageOS-devel] BLOCK APIs