I'd be much more comfortable doing this once direct-style IO lands in Mirage. mmap is a _really_ POSIX-oriented abstraction, and exposing it in all Mirage_block.S will add a fair bit of complexity to any implementations. It's true that it's simpler if you just restrict it to read-only, but there is still the problem of when to unmap something.
Note that access to the data is still determined by an underlying scheduler -- but instead of Lwt or the OCaml runtime, you are now depending on the page table subsystem to do this decision making for you. Do you have an example of a usecase you want to solve here -- is it for fairly small pieces of encrypted data? Anil On 7 Dec 2022, at 14:39, Romain Calascibetta <romain.calascibe...@gmail.com> wrote: > > Hi, > > It's not a real `mmap` but more a `read()` without `Lwt`. In the case when we > limit the access to the block (only for reading), it's fine to provide a > `read()` without a scheduling idea mainly because whatever what we do with > the block, it's a read-only block and data will be the same all the time. > The idea behind that is to unlock the ability to create a read-only > file-system and where the access of datas will not be determined by a > underlying scheduler. A new signature like: > ```ocaml > module type Mirage_block.RD = sig > type t > > val read : offset:int64 -> Cstruct.t > end > ``` > > Will allow us to make a `Mirage_kv.RO` and be able to compose such layout > (the file-system layout) with something else (like `ccm_block`). > > Best, > > On Wed, Nov 30, 2022 at 6:01 PM Anil Madhavapeddy <av...@cl.cam.ac.uk > <mailto:av...@cl.cam.ac.uk>> wrote: >> On 30 Nov 2022, at 15:13, Hannes Mehnert <han...@mehnert.org >> <mailto:han...@mehnert.org>> wrote: >>> >>> ## `mmap` available on `Mirage_block.S` (dinosaure, >>> https://github.com/mirage/mirage-block/issues/53) >>> - dinosaure has an implementation to get a part of the block (similar to >>> mmap), without being in the Lwt monad >>> - at the moment, read is in Lwt.t, i.e. does not block, but returns the >>> filled page(s) >>> - dinosaure needs a blocking function that returns the data >>> - the solo5 interface is already blocking (and synchronous), >>> mirage-block-solo5 adds the asynchronous stuff >>> - christiano mentions that it could be done with locking >>> - maybe develop a block read-only interface with a synchronous read >> >> In general, having "automatic" scheduling via mmap is a bad idea for >> anything non-trivial, since you slow to a crawl when under memory pressure >> and having a lot of page faults. There's no way a caller can determine >> whether or not a set of accesses will result in a blocking fetch or not. >> >> It may be workable for a read-only mmap, but... why do you want it? To get >> out of Lwt allocations? >> >> Anil > > > -- > Romain Calascibetta - http://din.osau.re/
