Re: MirageOS meeting 2022-11-30

[Romain Calascibetta <romain.calascibetta@xxxxxxxxx>]

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 <avsm2@xxxxxxxxxxxx> wrote:

On 30 Nov 2022, at 15:13, Hannes Mehnert <hannes@xxxxxxxxxxx> 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/