Re: TIME, CLOCK, RANDOM - use the linking trick instead of functors

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

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.alain@xxxxxxx wrote:
> Jan 21, 2025, 23:48 by hannes@xxxxxxxxxxx:
>
> > 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