> This is similar to the existing mirage/mirage-flow repo, only for `BLOCK`. > > Let me know what you think!
That's very useful. Would also useful be useful if we have unit-tests functors that BLOCK implementation can instantiate to check that they are correct. Haven't done that for mirage-flow, but that would be nice. Thomas > > Cheers, > Dave > > On Sat, Oct 17, 2015 at 12:33 PM, Thomas Leonard <[email protected] > <mailto:[email protected]>> wrote: > On 17 October 2015 at 12:24, Rupert Horlick <[email protected] > <mailto:[email protected]>> wrote: > > Okay, great. > > > > You’re right. So I should leave the connection to the generated main.ml > > <http://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] > >> <mailto:[email protected]>> wrote: > >> > >> On 17 October 2015 at 11:58, Rupert Horlick <[email protected] > >> <mailto:[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/ > >> <http://roscidus.com/blog/> > >> GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > > > > > -- > Dr Thomas Leonard http://roscidus.com/blog/ <http://roscidus.com/blog/> > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > <mailto:[email protected]> > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > <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
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
