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

[pierre.alain@xxxxxxx]

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