Hey,
thanks for your feedback.
The feedback is very positive for this change. Thomas mentioned we
should avoid `~deps:[ dep noop ]` and automatically insert a delay unit
argument (to Unikernel.start) if needed.
I did so in the mirage PR
(https://github.com/mirage/mirage/pull/1599/commits/c92714f934592ff8ff61bc81028fe77235ed158a)
printing a message on console that this was done. The mirage-skeleton
changes now look even cleaner.
Unless there's some objection, I'd really like to push this forward. We
can of course fix issues and clean up the code thereafter.
Best,
Hannes
On 22/01/2025 10:04, pierre.al...@tuta.io wrote:
Jan 21, 2025, 23:48 by han...@mehnert.org:
Dear everyone,
as discussed on the retreat last year, and in May 2024 on this list, and
further in the Mirage issue tracker, finally I went through the quite large
corpus of packages to provide a showcase how this will look like (including
working mirage-skeleton unikernels).
So, if you haven't followed the discussion, the idea is to use the linking trick (where
we use an OCaml interface for compilation, and when linking we provide the
"right" implementation) -- so our libraries do not need to be concerned about
the actual implementation. We use this for defining the interfaces for Mirage_sleep,
Mirage_mtime, Mirage_ptime, and also for Mirage_crypto_rng -- previously we already
applied this for Mirage_bootvar.
The result is that we no longer need to functorize over the TIME/PCLOCK/MCLOCK/RANDOM
"devices" in each unikernel.
Et voila, take a deep breath and look at the diff (ignoring whitespaces)
https://github.com/mirage/mirage-skeleton/pull/407/files?w=1 of our
mirage-skeleton example unikernel repository.
More details are in https://github.com/mirage/mirage/pull/1599, and even more
in the individual packages https://github.com/hannesm/mirage-time-defunctorised
(also https://github.com/mirage/mirage-sleep
https://github.com/mirage/mirage-mtime https://github.com/mirage/mirage-ptime).
It would be lovely to hear your thoughts on this. If it is positive, I'm keen
to open PRs and cut releases while the code is still hot, since otherwise we
may suffer from bitrot again.
Dear Hannes,
Thank for that huge work!
I'm really a huge fan for this move! From my POV, reading the code is not more
difficult as before (I might say even easier :) ), and so I completely approve
to merge the different PRs before time ran out and made them bitroted :)
Best,
Pierre
