/cc @Drup

Hi there, thanks for starting that discussion.

There are various things going on there: first mirage-os-shim has a weird position of trying to do things differently from the rest of the packages (and failing to compose properly with the rest of the ecosystem). I do think that this package has to disappear as it doesn't fit properly with the rest of the ecosystem so I am welcoming any change going in that direction.

However, let's step back a little: as far as I can see, mirage-os-shim is used only by mirage-entropy which is calling only the function at_enter_iter. I am fairly convinced that we can remove that dependency with a less intrusive patch :-) Also I strongly suggest we do not try to functorise over the scheduler implementation as I don't expect to see any program running with two different schedulers (especially after #1004). So we have two ways left:

• first, we can expose a Mirage_main function, which exposes only the scheduler hooks that Lwt_main is exposing (run, at_enter and at_exit). -- so using using the linking trick here should work and be legitimate. For names, Mirage_main is kind of similar to Lwt_main so it's ok, but Scheduler could also work (as it is exactly what this module is: hooks to interact with the thread scheduler).

• an other option (I am still not totally sure if it's a good idea) would just be to pass the scheduler around as a first class value. The only used function so far is at_enter_iter so that should be fairly easy to construct and pass around.

As usual, let me know what you think :-)

first, we can expose a Mirage_main function, which exposes only the scheduler hooks that Lwt_main is exposing (run, at_enter and at_exit). -- so using using the linking trick here should work and be legitimate. For names, Mirage_main is kind of similar to Lwt_main so it's ok, but Scheduler could also work (as it is exactly what this module is: hooks to interact with the thread scheduler).

This is the current solution used by mirage-entropy and mirage/mirage-os-shim#8 still continues to use it but provides a compatible solution with dune (eg. mirage-unix) and a plan to dunify MirageOS - and, by this way, avoids orchestration by ocamlfind.

As @hannesm said, if we look into the MirageOS eco-system, this solution does not really fit smoothly when a hack with functoria is needed (eg. deletion on mirage_impl_random.ml) and it's hard to really understand what is going on, like:

• where is mirage_os.cmx? (mirage-os-shim)
• who provides it? (mirage-solo5, mirage-unix or mirage-xen)
• what is the step to compile mirage_os.cmx with entropy.cmx? (-no-keeps-locs and ocamlfind)

So we can document it but the hack with functoria (which concerns ocaml-conduit at the end) still is needed. The hack is like: add a dependency between nocrypto and nocrypto-random (in terms of functoria) as dependency like application of functor Nocrypto_random (Nocrypto) but don't try to emit this application because I will do that myself my way.

On the other hand, as I said, playing with the linking-trick currently - with the current state of the MirageOS eco-system - is not so good when we have nothing (or, at least, ocamlfind) to orchestrate implementations under an interface. digestif is an example of that when a _tags is needed at the end to choose the right implementation - and it's not convenient to see a linking error otherwise.

But, as I said too, dune tries to solve that and if we do the migration to dune, see the usability of virtual_libraries and variants into the MirageOS eco-system should definitely be a proper and a good solution. But for this to work, we must compile a unikernel with dune first.

But at this stage, I would like to point another incompatibility: if we use virtual_library in dune, we don't have a way to trick or emit an other META file. mirage-os-shim and mirage-entropy still work because they continue to use topkg. Into details, a move to dune should be fine for mirage-entropy but a move of mirage-os-shim to dune will be more tricky (orchestration, if we look into mirage/mirage-os-shim#8, will be done by the mirage tool - but again, as the _tags file for digestif, it's a hands-written orchestration).

an other option (I am still not totally sure if it's a good idea) would just be to pass the scheduler around as a first class value. The only used function so far is at_enter_iter so that should be fairly easy to construct and pass around.

I'm more convinced by this solution when we can generate a main.ml with the right at_enter_iter and pass it by values however. This solution will completely remove mirage-os-shim and Mirage_random.S.initialize will take an at_enter_iter as an argument.

It still is a special case but as you said - and I agree with this - "we do not try to functorise over the scheduler implementation", The patch should be applied only into mirage-random-stdlib, mirage-entropy and mirage-entropy-nocrypto in the end, I think.

I'm very much in favor of removing the horrible hack around nocrypto/random/entroy in the mirage tool. It's very non-uniform with the rest and the fact that it works to begin with is an implementation accident.

I do not have much of an opinion on how to remove it, so I'll let you guys decide on that.

Regarding the name: when @dinosaure first showed me what he was doing, the name Mirage_main confused the hell out of me, because as far as I'm concerned, it already exists, it's this guy, and it makes no sense to functorize over that. So, let's pick another name.

I do like Scheduler, and @samoht idea to just provide the scheduler as first class value kinda make sense, notably since it already sort-of-happen as part of functoria: bind and return are part of the ambient scope, it would be an extension/formalization of that.

• TL;DR: let's leave mirage-os-shim alone and start a mirage-scheduler interface (with the four respective hooks at_enter_iter/at_exit_iter/at_enter/at_exit), release that, adapt mirage-entropy and the mirage utility, and get it out!

first of all: thanks @dinosaure, this is IMHO the way to go forward. some nitpicks:

• I like the name scheduler better than main as well (and now wondering whether Mirage_time -- providing the single sleep_ns function should be part of it? -- furthermore I had at various points the need for a cron like scheduling, i.e. Lwt_engine.on_time for MirageOS -- which would fit into a scheduler as well!) -- if we all agree on scheduler, this should live in its own repository (as our other module types)
• the run -- I'm no longer sure whether we should expose this or not, in the end we don't expect a user to care about it (neither call it ever)
• about functors vs first-class modules / linking trick: I like homogenous environments, functors are used everywhere in MirageOS, let's continue with that. first-class modules / linking trick comes out of nowhere and is hard to explain that I have a Scheduler.on_enter binding in my unikernel.ml -- this is esp. important if you think about tooling for developing unikernels (e.g. merlin) -- i don't quite understand how the first-class module approach would scale (for other devices -- which ones to have as first class modules, which ones as functor arguments) -- am happy to be convinced otherwise
• it's imho fine to have run/bind/map special (using whatever trick) since a user is not confronted with this - not supposed to call it. let's reduce the tricks we need in mirage/functoria and improve the tooling ;)
• while toying around with noconfig (rough prototype, but already working on lots of mirage-skeleton examples), I'm more and more convinced that config.ml contains mainly redundant information (that can be derived from unikernel.ml), and we can improve usability (developer experience, merlin integration) quite a bit by even further using functors in unikernel.ml -- i.e. is there a reason why boot arguments and app_info are not done via functor arguments? -- both are atm rather unfriendly in my emacs since key_gen is generated and merlin won't know much about it -- but that's something to discuss elsewhere