Re: [MirageOS-devel] BLOCK APIs

[Thomas Leonard <talex5@xxxxxxxxx>]

On 17 October 2015 at 12:24, Rupert Horlick <rh572@xxxxxxxxx> wrote:
> 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.

Eventually, yes. For testing, I'd suggest your test unikernel should
take a plain block device and pass it to ORAM.connect manually. Then
update the mirage tool with ORAM support at the end.

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



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