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)
