In terms of 'lines of code running' wouldn't a stripped down Linux kernel + Mirage application in direct mode beat
Xen + Linux dom0 HW drivers + Linux dom0 Xen daemons/tools + Mirage unikernel?
I do agree with you that Xen is probably better at providing isolation than Linux, i.e. it is better at what
an OS is supposed to provide :)
Also if you are in an environment where your only option is to deploy Xen domUs, i.e. like EC2, then you probably have a performance advantage as well because you just eliminated one layer.
In the end not much changes conceptually compared to a traditional application:
* instead of being linked with libc it is linked with Mirage's runtime
* its "OS" is now Xen instead of Linux
* the drivers of the OS are unchanged (running Linux in dom0)
* developing a Mirage unikernel is much like developing a traditional application, if you restrict yourself to the Mirage provided interfaces
> In terms of 'lines of code running' wouldn't a stripped down Linux kernel + Mirage application in direct mode beat Xen + Linux dom0 HW drivers + Linux dom0 Xen daemons/tools + Mirage unikernel?
Well, you can drop into a driver domain model and not have a full Linux dom0 (if you don't mind fixing on a particular hardware model).
But don't forget that Mirage is about modularity though -- we have a kernel module version under development too, and a baremetal rPi one. The idea is that as the number of libraries grow, it becomes easier to pick and choose the set you need for the particular deployment environment you want to build an application on (including but not exclusively a Xen unikernel).
I do agree with you that Xen is probably better at providing isolation than Linux, i.e. it is better at what an OS is supposed to provide :)
Also if you are in an environment where your only option is to deploy Xen domUs, i.e. like EC2, then you probably have a performance advantage as well because you just eliminated one layer.
In the end not much changes conceptually compared to a traditional application: