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

Re: [MirageOS-devel] BLOCK APIs

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.