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 <[email protected]> wrote: > On 17 October 2015 at 12:24, Rupert Horlick <[email protected]> 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 <[email protected]> wrote: > >> > >> On 17 October 2015 at 11:58, Rupert Horlick <[email protected]> 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 > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > -- Dave Scott
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
