On the one hand, I applaud the effort to simplify the software stack and promote the use of a safe language all the way down.
On the other hand, I wonder if running lots of small OS kernels on a hypervisor is the best way to do this. Might it be better to simply run each application as a process on a conventional OS kernel, perhaps with containers for isolation? This post from Brendan Gregg argues pretty convincingly that virtualization imposes a substantial performance penalty:
http://dtrace.org/blogs/brendan/2013/01/11/virtualization-pe...
I understand that a key premise of the unikernel approach is that the millions of lines of C code in a conventional OS kernel like Linux are a problem. But in any real Xen deployment I'm aware of, Linux is running in dom0 anyway. So why not take Xen out of the picture and run each application as a process in a container on Linux, using raw sockets so you can still implement the TCP/IP stack in OCaml? For deployments on Amazon, I guess the unikernel approach has the advantage that you're running on top of Xen anyway, so you're eliminating a layer. But for running on one's own servers or an ARM-based device like the Cubieboard2, it seems to me that Xen is just complicating things.
I guess one benefit of Mirage's use of the OCaml module system is that we can experiment with multiple deployment approaches and use whichever one works best in practice. So there's nothing stopping me from running a Mirage application on Linux with raw sockets rather than as a Xen unikernel.