This repository was archived by the owner on Mar 11, 2020. It is now read-only.
Merge several versions back into one#31
Merged
Merged
Conversation
Merge the two opam-level packages back into one. Deal with variations of C stub build options through the `_linkflags` mechanism. Cheese, sausages, crackers, and absolutely indispensable `topkg` support provided by @dbuenzli.
Bounce the single call into Mirage API over a shim lib for the intersection of the OS API provided by the backends.
Contributor
Author
|
A simple unikernel generating keys works on |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is my take on how to support multiple backends.
There are two reasons for splitting the lib into
-xenand-solo5specific ones, neatly conflated. One is that the stubs need different compilation options for the two backends. This is easily solved through existing_linkoptsmechanisms. 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
OSmodule 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 thecmito the client, and sealing the deal by using-opaquecompilation to prevent any information not in thesigfrom leaking out. The shim passively redirects to the right implementation, as long as mirage exposes this information.The benefits of this are:
miragetool needs to know less about us.nocrypto, does not need to know anything about target-specificity here. This is a completely private detail.unixflavor, so entropy can now be used wherever.I welcome testing, particularly on solo. And obviously, this hinges on the mirage PR.