As before, this is what we talked at the meeting (the source comes from:
https://pad.data.coop/wGS4r8RyTKqQ73mcw7FrwA?both)
# MirageOS community call
### 26/02/2024
- Present: dinosaure, Pierre, Hannes, Virgile, Thomas G. Thomas L., Samuel,
Shakthi, Magnus
- Agenda:
- Meta:
- Should we use Zoom or something else?
- Pierre: Some universities cannot use Zoom on Linux.
- Dinosaure: Prefers to use Jitsi.
- Virgile: Can use Renater (which uses Jitsi) if someone has a
renater account.
- Pierre-Alain will investigate.
- Hannes: there is the public instance jit.si where no
registration is necessary (as used e.g. in the opam-repository meetings)
- Should we use https://pad.data.coop/ or something else? => Pad
seems good!
- Anyone willing to help organising these calls? (send , taking
notes, etc.)
- Next meeting will be organised by Magnus :-) Thanks (and
Virgile is also happy to help)
- MirageOS retreat update?
- 16 people signed up! early-birds registration seems to work fine
- still space available - even for a few days and/or for the
week-end
- mix of people that have been there before, and new people!
- PR updates
- solo5+ocaml5: https://github.com/mirage/ocaml-solo5/pull/124
- Samuel and Fabrice are trying to revive the PR. Cleaning up
the x-compiler story for the OCaml compiler in a state that could be
upstream. The goal is to clean up all the pieces are glued together. Still
trying to understand how the various details are working (like memory
allocation). Target: OCaml 5.2 (which include compaction) as many things
have changed.
- Hannes: there are 2 or 3 PRs that pretend to do something
with OCaml 5. Some of them have a lots of comments from Christiano and
others. Is there a plan to merge/review those comments too? Some stuff
implemented in C were a bit brittle. Would be sad if we lose these reviews.
- Samuel: plan is probably to open a new PR that adress all of
the comments (#122, #124, #129). Many things have changed in 5.2.
- Dinosaure: what's the issue with x-compilation? Samuel: many
ways in the way ocaml-solo5 works is to patch the OCaml build system (with
a few things broken as a result). Things are very brittle. We would like to
have something more solid. Dinosaure: this seems independant? Could we
decouple those concerns? Samuel: indeed. currently trying to understand how
things work but the idea is to reduce the maintenance as well. and to
understand what is needed for solo5 vs. x-compilation. Dinosaure: see
ocaml-solo5#123 (most issues are related `configure`). Samuel: will talk to
Sebastien next
- mirage runtime keys v2: https://github.com/mirage/mirage/pull/1493
- Thomas:
- use cmdliner directly, instead of a custom fork
- keys are split into configuration time keys and runtime
keys
- the runtime ones are only defined at runtime
- it is a breaking big change
- Hannes:
- configure-time: you select what libraries you want to use
in the unikernel (keys)
- runtime-time: you select some runtime parameters (ip
address, etc.)
- better type for key
- issue: type errors, locations in generated code
- Happy with the current state but do not have time to
review fully
- Thomas:
- updated existing unikernels
- worked on error locations (you need to pass `__LOC__`)
- there's a OCaml compiler patch that does this automatically
- ~all examples and documentation will need to be updated to
reflect the new interface: big workload
- Hannes: can we remove the dependency between mirage and
mirage-runtime
- Dinosaure: the idea looks good, and the possibility to add
custom types (via cmdliner) is nice
- Thomas: will make progress for the next call
- MirageOS relies on "opam-monorepo", what is the schedule switching to
"dune pkg" (last was "Q1/2024" - anyone actively working on that)?
- the dune and opam team worked for the last year to include
opam-lib into dune
- dune will be able to compute (make a lock file), download packages
it needs locally, and compile each opam package (even if the package is not
using dune)
- single tool to define dependencies, whenever you modify the dune
file, the opam packages are updated
- rules will be cached
- it is similar to opam-monorepo
- packages need to be relocatable (not all are, e.g. the compiler)
- there'll be a small overlay (similar to opam-monorepo overlay) for
a small set of packages that are not possible to build with "dune pkg"
- timeline: first alpha was planned end of Q1, now scheduled for May
- what needs to be done for mirage? we haven't tested it yet. need
to discuss and test once an alpha is around (thomas will test even earlier)
- for now we need to keep opam-monorepo
- Thomas: are there urgent pains to address?
- Hannes: hard to use old versions of dunes, ...
- Hannes: Is there any specification of how dune pkg will
download/organize etc., for the purpose of reproducible builds? -- Thomas:
it created a lock file and downloads using opam-lib
- Hannes: carton/git issue with opam-monorepo -- Thomas: this will
be fixed in "dune pkg"
- Dune pkg milestone:
https://github.com/ocaml/dune/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Package+Management+MVP%22
- dune+orb (reproducible build integration):
https://github.com/ocaml/dune/issues/9548
- Performance considerations for MirageOS (let's take mirage-crypto as
example)
- EC NIST curves pre-computed tables --
https://github.com/mirage/mirage-crypto/pull/191 shows a speedup of 4x
- mirage-crypto symmetric cipher (AES-GCM / Poly1305-Chacha20)
around 10x slower than OpenSSL (see
https://github.com/mirage/mirage-crypto/pull/203, a speedup of ~2.5x for
chacha using string/bytes)
- cstruct.t vs bytes --
https://blog.robur.coop/articles/speeding-ec-string.html shows a speedup of
2.5x
- or replace the underlying structure of cstruct from bigarrays to
bytes? "Just" have to take care of IO-pages which still need aligned
addresses
- for Xen interfaces we need page-aligned non-moving memory areas
- Dinosaure: don't use _systematically_ Cstruct‧t and probably we
should use bytes more systematically and asking ourselves about
particularities of bigarray
- Thomas: Patrick has started a Bstruct library:
https://github.com/ocaml-multicore/ocaml-uring/pull/101
- mirage-flow + shutdown (https://github.com/mirage/mirage-flow/pull/48)
- Hannes: released to opam-repository as mirage-flow 4.x
- Hannes: anyone eager to review:
https://github.com/mirage/mirage-tcpip/pull/512
- Thomas: will ping Dave
- Next meeting - https://meet.jit.si/mirageos-call, 9 CET in two weeks
(March 11th)
### Moved to next meeting
- Unikraft+mirage plans
- How can we improve the security story around MirageOS? What are the
security issues with mirage?
- What do we want Mirage5 to look like?
- Ocaml 5 support
- No more Lwt?
- IncludeOS / Mirage
As decided, the next meeting will be on March 11th (9 CET). We decided to
use Jitsi now (instead of Zoom): https://meet.jit.si/mirageos-call
Thanks for your participation.
On Mon, Feb 26, 2024 at 8:55 AM Thomas Gazagnaire <tho...@gazagnaire.org>
wrote:
> Reminder, the MirageOS bi-weekly meeting is happening in 5 minutes.
>
> Zoom link:
> https://us06web.zoom.us/j/85369924110?pwd=Wj7Hhu79mBH4eiQbequQVjwdOLkZRq.1
> Agenda: https://pad.data.coop/wGS4r8RyTKqQ73mcw7FrwA
>
> See you there,
> Thomas
>
>
>
--
Romain Calascibetta - http://din.osau.re/
