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

Re: [MirageOS-devel] BLOCK APIs



On 17 October 2015 at 11:58, 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?

I don't think so. It does the same thing (apart from also defining the
deprecated "id" type, which could be removed now).

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

What do you need it for? You should be able to define your own connect
method that takes an instance of the underlying block device and wraps
it with your type. You shouldn't need to call the underlying device's
connect method yourself (and different devices will require different
arguments).

Actually, the current "connect" signatures aren't very good. Ideally,
mirage-block-xen's connect function would take a XenStore argument,
for example, rather than fishing one out of the environment.

> It would be great to clarify these points before I move ahead with the
> implementation.
>
> Thanks,
>
> Rupert


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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