This is my take on how to support multiple backends.
There are two reasons for splitting the lib into -xen and -solo5 specific ones, neatly conflated. One is that the stubs need different compilation options for the two backends. This is easily solved through existing _linkopts mechanisms. I'd argue that it also should be solved through these, because a separate library name is not an appropriate container for a C compilation flavor that is completely invisible on the OCaml level.
The second reason is trickier, in that entropy hooks into the event loop. This is provided by the OS module of all backends in a uniform way. The problem is that linking to that module as exposed by any one library fixes the compiled code to that library.
The second part can be solved by shimming over (the common part) of OS, exposing only the cmi to the client, and sealing the deal by using -opaque compilation to prevent any information not in the sig from leaking out. The shim passively redirects to the right implementation, as long as mirage exposes this information.
The benefits of this are:
It demonstrates a technique to avoid the explosion of spurious libraries that contain exactly the same code.
The mirage tool needs to know less about us.
Any dependent library, like nocrypto, does not need to know anything about target-specificity here. This is a completely private detail.
Lastly, it was easy to add the pure unix flavor, so entropy can now be used wherever.
I welcome testing, particularly on solo. And obviously, this hinges on the mirage PR.
This is my take on how to support multiple backends.
There are two reasons for splitting the lib into
-xen
and-solo5
specific ones, neatly conflated. One is that the stubs need different compilation options for the two backends. This is easily solved through existing_linkopts
mechanisms. I'd argue that it also should be solved through these, because a separate library name is not an appropriate container for a C compilation flavor that is completely invisible on the OCaml level.The second reason is trickier, in that entropy hooks into the event loop. This is provided by the
OS
module of all backends in a uniform way. The problem is that linking to that module as exposed by any one library fixes the compiled code to that library.The second part can be solved by shimming over (the common part) of
OS
, exposing only thecmi
to the client, and sealing the deal by using-opaque
compilation to prevent any information not in thesig
from leaking out. The shim passively redirects to the right implementation, as long as mirage exposes this information.The benefits of this are:
mirage
tool needs to know less about us.nocrypto
, does not need to know anything about target-specificity here. This is a completely private detail.unix
flavor, so entropy can now be used wherever.I welcome testing, particularly on solo. And obviously, this hinges on the mirage PR.