Microkernels vs. hypervisors (2008)

At least back in the days of the first Android phones and the original iPhone, smart phones needed at least two cores, and they dedicated one core to a real-time microkernel to run the cellular radio and other to run Linux &#x2F; Xnu and the Android&#x2F;iOS applications.<p>These days, do Android and iOS run paravirtualized kernels on top of the real-time microkernel so that they don&#x27;t have to dedicate a whole core to managing the radio and other real-time tasks? Do they still dedicate a (smaller?) core to the RTOS? Paravirtualization involves fewer changes than making an existing OS Kernel into a hard-realtime low-latency kernel, but it&#x27;s also possible that modern Android and iOS phones use hard-realtime low-latency Linux and Xnu kernels. Blackberry&#x27;s QNX started out using a hard-realtime low-latency kernel as the application kernel, so it&#x27;s more likely blackberry is using QNX to control the radio and other hard-realtime tasks instead of running a second microkernel on the phone to handle the radio.

The real question is, what is the interface you are virtualizing, and how do the characteristics of that interface influence the design of the OS you are building?<p>Hypervisors virtualize the hardware interface: the user-mode and privileged-mode instruction sets, the I&#x2F;O ports and channels, the memory model. This is good because that interface is stable and well-understood, allows for a high degree of isolation between processes, and has a large number of applications (operating systems) already written to the interface ready to run on the hypervisor. This is bad because the interface is more low-level than one would like as an API for programmers, requiring another layer (the OS or at least kernel) to make it usable.<p>Microkernels, or kernels in general, provide a system-call interface that is made up by the OS designer. This is good and bad in a mirror image sort of way vs. the hypervisor. It is good because the interface is more suited to programmers, providing OS level services rather than presenting as bare metal. It is bad because the interface is less stable (evolving in software time rather than hardware time), less provably or practically isolating between processes, and has a smaller ecosystem of applications already written to that interface (perhaps zero if it&#x27;s brand new).<p>It is useful to view kernels, microkernels, and hypervisors as points on a spectrum of virtualized interfaces. One can see hypervisors moving towards kernels with virtual additions to the hardware interface, such as paravirtualized I&#x2F;O devices, special trap instructions to communicate with the hypervisor, and optimizations such as page sharing, snapshotting, and live motion.<p>Microkernels can also be viewed as moving to a smaller, cleaner system call interface on the spectrum, with greater stability and isolation between processes than a &quot;big&quot; kernel. But the issue of lack of applications written to the interface remains.<p>The ascent of Linux containers hits a sweet spot on this spectrum IMO. Linux containers virtualize the Linux system call interface, which has become relatively stable, certainly has a large body of applications written to it, and provides a &quot;good enough&quot; degree of isolation among its containers (which keeps improving).<p>IMO the ascent of Linux containers is on a hockey stick curve right now (due to Docker having simplified and standardized its interface and container format&#x2F;management) and will overrun any debate like this between hypervisors and microkernels, for those of us not doing academic OS research. Virtual machines will not go away, but will be used more for their original purpose, to allow running completely different OSes on the same hardware, and to provide completely isolated OS instances, rather than as general purpose compute capabilities a la IaaS.