Absolutely – we actually use MirageOS libraries in this way inside Docker for Mac and Windows (as an embedded piece of a bigger non-OCaml application).
The specifics are somewhat at the vagaries of the build system of our individual libraries however, and this is something that’s being actively improved. Some notes in no particular order:
- The Ctypes makes it easier to separate the description of the foreign C code to run from the linking mechanism. This is key to retaining flexibility in how we link code, without having to rewrite all the foreign function bindings. So if you do build a foreign interface, we highly recommend the use of Ctypes to start new code with.
- The Solo5 project has given us two alternative hypervisor backends in Mirage (Xen and KVM). This means that the way we build C libraries is changing to be more general and easier to integrate. Dan Williams and Martin Lucina are working on this and should have an update soon.
Ctypes is so powerful as a linking library because it not only lets you link to C libraries, but it also lets OCaml code expose a C interface that can be called from C code. This is known as “inverted stubs”, and forms the basis for how MirageOS can act as a kernel of sorts by exposing a C ABI for other code to run.
Now, the question is: what should these C APIs that Mirage exposes look like? Should they be boring old POSIX, which Mirage can only do an imperfect job at emulating (quirks, bugs and all), or should be the cleanest C interfaces that we can come up. One experiment we’re working on is inverted tls, where we expose the OpenBSD libtls API that is a significantly saner version of the TLS APIs than OpenSSL’s.
What sort of non-OCaml programs did you have in mind when you raised the question?