Re: [MirageOS-devel] BLOCK APIs

[David Scott <scott.dj@xxxxxxxxx>]

Hi,

FYI I just found myself writing a generic `copy` function over `BLOCK` devices for about the 100th time so I've created a repo called `mirage-block` to contain generic functions over block devices. The kinds of things I have in mind are:

1. copy

2. erase

3. mirror

4. Linux device-mapper like virtual devices

5. perhaps helper functions to handle alignment constraints when laying out structures on disk?

This is similar to the existing mirage/mirage-flow repo, only for `BLOCK`.

Let me know what you think!

Cheers,

Dave

On Sat, Oct 17, 2015 at 12:33 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:

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

--

Dave Scott

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel