BTW I'm happy to write a quick example to illustrate any intended use case you have in mind.
On 5 May 2017 at 21:36, Mindy <[email protected]> wrote: > On 05/05/2017 02:56 PM, Tom Ridge wrote: > >> Yes it is very easy. Please see the disk_ops type in the API. >> >> (** Disk operations: read, write, and sync *) >> type 't disk_ops = { >> block_size: BLK.sz; >> read: BLK.r -> (BLK.t,'t) m; >> write: BLK.r -> BLK.t -> (unit,'t) m; >> disk_sync: unit -> (unit,'t) m; >> } >> >> Also the disk_to_store function, and store_to_map. So if you have a >> disk_ops (or store_ops) you can get a map_ops. But really this is a >> B-tree library. More work needs to be done to get an efficient KV store, >> or filesystem or whatever. But yes, it is already done - I looked at the >> Mirage block interface a while ago and it seems reasonable and close to >> what disk_ops assumes (which isn't much). >> > > Nice, thanks! > > BTW what was confusing about the structure? Did you read the overview? >> >> https://tomjridge.github.io/tjr_btree/Tjr_btree_doc.html >> > > Nope, I just read your included example and went to the repository and > started digging around in it; I didn't notice your "documentation" link at > the bottom the README, but indeed it's there. > > Thanks for your interest! >> > > Thanks for your work and the announcement! > > -Mindy >
_______________________________________________ MirageOS-devel mailing list [email protected] https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
