Re: Next MirageOS meeting 2024-06-10

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Hello,

our next meeting is in two weeks, June 10th at 09:00 CEST 
(https://www.timeanddate.com/worldclock/fixedtime.html?msg=MirageOS+call&iso=20240610T07&ah=1)
As usual everyone is welcome to attend this bi-weekly meeting. The 
current agenda is here: https://pad.data.coop/wGS4r8RyTKqQ73mcw7FrwA
Feel free to add any additional items you'd like to discuss. The Jitsi 
link for the meeting is https://meet.jit.si/mirageos-call

The notes from today's meeting:
Participants: Pierre, Thomas G., Shakthi, Sabine, Hannes, Samuel

Agenda:
- mirage 4.5.0 and 4.5.1 released \o/
- the dune-variant approach for defunctorisation
- OCaml-solo5 goes OCaml 5.2
    - merge and add a branch for Ocaml 4.4?
- next meeting june 10th 09:00 CEST

Notes:
#### mirage 4.5
- Hannes: we have made a new release of Mirage!! Mirage 4.5 splits 
runtime and configuration time keys. 4.5.1 fixes a few bugs (and adds 
one breaking change). mirage-skeleton has been updated - all Hannes' 
unikernels as well. Mirage doesn't depend on mirage-runtime anymore. 
Summary: seems to work great!
- Pierre: qubes-mirage-firewall also uses mirage 4.5
- Thomas: 4.5 was released just before the retreat, so we had time to 
find some bugs in that
#### dune variants / defunctorisation
- Hannes: Lucas added dune variant in Dune when we released mirage4. The 
idea was to use this but we dropped the idea at the time. Investigated 
using dune variants instead of functors durung the retreat. The result: 
4.5.1 now uses dune variant for mirage-bootvar (used to be 4 
repositories! now just one that uses variants and works nicely). The 
code is much clearer: a single repo - easier to compare the various 
implementation for unix/xen/solo5. Bigger topic: could we generalise 
this to the entire network stack. Also for the time device. Hit a bug in 
Dune (https://github.com/ocaml/dune/issues/10460) - found a small repro 
case and reported to Dune. Rudi found a fix and Dune master is now 
fixed. How do we move forward now?
- mirage-time defunctorisation https://github.com/mirage/mirage/pull/1529
- Thomas: where to get rid of functors?
  - everywhere? at the application side, everything should be static
  - but when you write libraries, it is a bit unclear
  - also for testing
  - if you look at the file system / block device stack, you may need 
some flexibility here
  - it is useful to get rid of functors where we can
- Thomas: if there's a way to keep functors when we develop the 
libraries, but the exposed interface is very simple (no functor)
- Thomas: error messages -- if you're using Time, but forget the 
dependency, you get not so nice error messages
- Hannes:
    - Time/Clock/Random: no need for functor
    - mirage-net/ethernet/arp: no need for a functor
    - Block: CCM/partioning; VPN: also provide a network stack - here 
having a functor makes sense
- Thomas: we expose some internal complexity (what is functorised / what 
is not?) to the user - how to communicate to the user whether a device 
is functorised or not (put it on the extra_deps vs in the type (`@->`) 
and application (`$`))
- Hannes: maybe `extra_deps` is not the right thing -- since we want to 
depend only on `mirage-time` / `mirage-clock` with the target-specific 
implementation
  - Samuel: we can add a dependency on mirage-time / mirage-clock in 
all the unikernels
- Thomas: for the RNG it is a bit more complex, since we need to call 
the `initialize` function
- Samuel: maybe we could always link time and clock with the unikernel - 
everyone: good idea!
- Hannes: let's wait for the Dune release with the fix about dune 
variants - and make progress on time/clock!
- Pierre: this is a good move, but the mirage-block-ccm should stay as is :D
- Thomas: the question is where do we want this flexibility? Look at POSIX
   - Hannes: this is a great analogy - on UNIX systems we have tun/tap 
devices (for VPN etc.), and also block devices which support encryption 
-- so maybe at the device level it makes sense to have the abstraction
#### OCaml 5 + solo5
- https://github.com/mirage/ocaml-solo5/pull/134
- Samuel: the behaviour with the GC changed a lot in OCaml 5, someone 
has a good example to test a long-running unikernel?
- Hannes: maybe the retreat website, where we graph the memory usage 
(and thus have a comparison between last months and with OCaml 5)
- Samuel: didn't manage to compile mirage-www yet, stuck in opam-monorepo
  - Thomas will look into that issue this week
- Pierre: will swap his qubes-firewall to OCaml 5 this week, last week 
saw ~10-20% performance improvement with OCaml 5
- OCaml 5.2 supports compaction now, but we've to manually call 
`Gc.compact ()`
- Pierre: at the early OCaml 5 stages, each domain allocated 2MB stack - 
we set the maximum domains to 1 in ocaml-solo5
- Samuel: when ocaml-solo5 is built, it sets the number of domains to 1
- Pierre: solo5 already reserves 1MB for the global stack

#### MirageOS and Unikraft
- Samuel: there are small examples, currently quite a lot needs to be 
done manually
- Samuel: the question is who drives the build, unikraft wants to have 
control, mirage as well
- Samuel: we will need something like ocaml-unikraft (similar to 
ocaml-solo5), at the moment `musl` is used
- Samuel: there's some basic support for SMP in unikraft, but not yet 
enough for OCaml (scheduling)
- Samuel: from performance perspective, one thing that is interesting is 
the support of ring interfaces
- Thomas: the build system changes, we should talk with unikraft so that 
they're aware of what we do (and if they change stuff, we get informed)