Hey,
here are the notes from our meeting. Next meeting next week (Monday
20th, 09:00 CEST
https://www.timeanddate.com/worldclock/fixedtime.html?msg=MirageOS+call&iso=20240520T07&ah=1
Participants: Thomas G, Kaushik, Rajesh, Pierre, Samuel, Vincent Balat,
Hannes, Reynir, Pixie
Agenda:
- MirageOS retreat
- Hannes: It was amazing! Good food! 17 participants (1/3 who came
by bus/train). Lots of discussions about deployments. Lots of good
discussion focused on documentation. ~10 PRs to the mirage website. Lots
of different stuff happening. Blog posts are upcoming. Jules ported
unikernels to mirage 4.5. Found a few issues and opened PRs. Thomas to
check those.
- Mirage and Dune virtual libraries (defunctorisation)
- Hannes: found a few issues in dune variants. That seems to be a
good idea. Discussed with Leandro and Vincent to port bigger libraires
([Riot](https://github.com/riot-ml/riot) and Ocsigen) to Mirage. It was
not easy to them because of functors. Related to Time/Clock/Random issue
with defunctorisation. Experimented with conditional compilation and
dune variants. The complicated part is the network stack. But actually
we do not need functors for the network stack. Current status: lots of
overlays but succeeded to build the network example in the tutorial
(using the TCP/IP stack) without functors. Still working on how to
reproduce the Dune issues for the Dune team to fix.
- The motivating example: think of a network device (mirage-net),
for a given target (unix/solo5/xen), we'll only ever want the one
network interface implementation
(mirage-net-unix/mirage-net-solo5/mirage-net-xen) -- and don't want to
mix them --> we can use dune variants (or conditional compilation)
- another motivation is the clock implementation: who would want a
unikernel with two different clocks
- Thomas: really interesting to simplify the functor stack for the
80% of use-cases. What about virtual network:
https://github.com/mirage/mirage-vnetif? What about the storage stack
(where the "default storage" is harder to define)
- mirage-kv - you may want to have a KV store backed by memory and
a KV store backed by memory in the same unikernel -> functors are fine here
- mirage-block - same argument as mirage-net -- we will only have a
single implementation (depending on the target --
mirage-block-unix/mirage-block-xen/mirage-block-solo5) -- and not mix them
- Thomas: interested in keeping the functors for "special" applications
- ocsigen porting issues
- (a) functors (you need to refactor your code to have a module that
is functorized and the shared code elsewhere, so you need to call the
code indirectly)
- (b) static bundled files (maybe a tar archive)
- (c) logging (there's syslog)
- (d) configuration files (is dynlink supported by MirageOS? no. but
there's a path to include the configuration into the binary)
- (e) Makefile and build system (MirageOS builds in a dune monorepo)
- OCaml 5
- Samuel: the PR for solo5 + OCaml 5.2 is opened. A few extra
patches to be pushed soon.
- Samuel: started exploring the unikraft backend with Fabrice (to
be as similar as possible as the solo5 changes)
- Pierre: to try on mirage-qubes-firewall; Samuel and Thomas will
try to test it with mirage-www
- Pierre: what's the status with io-page/allocations? Could you
rebase the PR on the head of ocaml-solo5 to simplify testing? Samuel
will - no changes to the allocator so should merge fine.
- Ocsigen + Dream
- kaushik: what is the difference / where does it sit?
- kaushik: what does dream offer? is it a subset of ocsigen?
- kaushik: ocsigen: fully end-to-end framework, dream: API for server
- vincent: what you can do with dream, you can do with ocsigen - but
ocsigen is a full stack, you can do more with it
- vincent: dream is likely easier to use if you're only developing on
the server side
- vincent: with ocsigen, you can integrate client-side as well, and
go the full way to mobile applications
- thomas: dream works with mirageos, ocsigen not yet
- thomas: mirage-www uses dream (it is only a static site)
- vincent: people start with dream, and then want to add features and
need to do everything manually -- think when you start where you want to go
- next meeting in two weeks (may 20th) 09:00 CEST
