But the entire point is that unikernels <i>aren&#x27;t</i> like the Linux kernel, that there <i>isn&#x27;t</i> a userspace&#x2F;kernelspace boundary in the way that there is on Linux and other traditional OSes.<p>From the paper (<a href="http:&#x2F;&#x2F;unikernel.org&#x2F;files&#x2F;2013-asplos-mirage.pdf" rel="nofollow">http:&#x2F;&#x2F;unikernel.org&#x2F;files&#x2F;2013-asplos-mirage.pdf</a>):<p>&gt; We present <i>unikernels</i>, a new approach to deploying cloud services via applications written in high-level source code. Unikernels are single-purpose appliances that are compile-time specialised into standalone kernels, and sealed against modification when deployed to a cloud platform. In return they offer significant reduction in image sizes, improved efficiency and security, and should reduce operational costs. Our Mirage prototype compiles OCaml code into
unikernels that run on commodity clouds and offer an order of magnitude reduction in code size without significant performance penalty.<p>&gt; An important decision is whether to support multiple languages within the same unikernel. [...] The alternative is to eschew source-level compatibility and
rewrite system components entirely in one language and specialise that toolchain as best as possible. [...] existing non-OCaml code can be encapsulated in separate VMs and communicated with via message-passing [...]<p>&gt; We did explore applying unikernel techniques in the traditional systems language, C, linking application code with Xen MiniOS, a cut-down libc, OpenBSD versions of libm and printf, and the lwIP user-space network stack.<p>That is, there is absolutely a single language constraint, on purpose, as arguably the primary differentiation from non-unikernels.