Re: [MirageOS-devel] BLOCK APIs

[Rupert Horlick <rh572@xxxxxxxxx>]

Okay, great.

Youâre right. So I should leave the connection to the generated main.ml and 
even have it connect to my device there as well, passing my implementation 
through to the start method in the Unikernel.

Thanks for the help,

Rupert

> On 17 Oct 2015, at 12:17, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> 
> 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