| Got it -- so you want to interface with hardware drivers via passthrough to a driver domain, I think.
The best way to think of Mirage is as a growing bunch of libraries, glued together by a minimal runtime for whatever platform is targetted and an increasingly sophisticated constraint-based package manager (OPAM).
For example, consider these backends:
- UNIX --- the compiler output is an ELF executable, and started/stopped via a helper binary that passes it file descriptors and performs privileged operations. It can be passed raw packets via tuntap, or invoke kernel sockets, depending on how it's built.
- Xen -- the compiler output is an object file that is linked to a minimal Xen OS with a linker script to make it PV bootable. All the drivers are normal OCaml libraries (including the shared memory ring handling).
- _javascript_ -- the compiler output is a JS blob which has externals that are satisfied via other _javascript_ functions made available, and the runtime used is the _javascript_ one.
- kFreeBSD -- the compiler output is linked with the OCaml GC and fixed-point floating point and kernel module scaffolding. The internal kernel APIs are bound as OCaml libraries.
The final one is the most relevant to you...the easiest way to manage hardware in the first instance is to use FreeBSD as a driver domain (no userspace), and take advantage of existing Mirage libraries to manage the kernel lifecycle.
The most immediate thing to get working in the kernel guest is Xenstore. This is exposed to a HVM guest via a special MSR which gives you the shared_info page, which in turns gives access to hypercalls and the Xenstore event channel. Once this is set up, you can use the existing OCaml Xenstore library to handle all the communication to/from the driver domain, without having to worry about reimplementing the protocol in the kernel. The same goes for other virtual devices such as Netfront, Blkfront, and (thanks to Dave) even a VNC framebuffer if you want a PV framebuffer.
On your other points about filesystems -- Thomas Gazagnaire is working on a Mirage filesystem at the moment (a branch-consistent one dubbed Irminsule), and Dave has a FAT32 implementation, and I wrote a simple static one (in mirage-fs). We're finding that filesystems aren't often required by our current applications, however.
Hope this helps -- if you let us know more specific use-cases, I can guide you towards more specific solutions.
cheers, Anil Thank you Anil.
I am working with baremetal port of mirage (well on top of xen in dom0 domain) and I'm expecting to have a lot of hardware drivers which I'd like to deploy and debug without rebuild of entire mirage image. Also I'd like to have a way of upgrading software and it is better done with in-system compiler or bytecode interpreter. As far as I understood your answer mirage ocaml does have bytecode interpreter but does not support filesystem or other modules sources, am I right?
Unikernel solution is good for me for now but it is way too long to debug anything with unikernel and I expect it to become worse in future.
| 
