Learning KVM – implement your own kernel

Ok, we've s/Linux //'d the above.

No, it's more akin to a unikernel[0]. Technically all kinds of processes will run in a container, but in a unikernel, there is really only one process.

I believe this kernel will similarly run a single ELF binary, but I believe it does do some memory mapping, potentially (I've only scanned it quickly, however).

[0] https://en.wikipedia.org/wiki/Unikernel

Matter of definition.

Linux containers are 'just' processes that run directly on an existing Linux kernel all together. A kernel feature called namespaces gives these processes their own view of memory, the file system, etc.

What's being described in the article isn't a conventional process. Rather, the article describes using Linux's KVM virtualization capability to launch a virtual CPU that is running another kernel. A virtual machine is like an emulator - hardware being simulated in software. The article is describing how to launch that VM, and how to build a minimalist kernel that runs inside it. This is similar to the setup that one might use in a college operating system course to run an under-development guest kernel on a host system. The under-development guest kernel can then run processes of its own.

(Since the design of this mini-kernel contemplates both a kernel mode and user mode, I would not call it a unikernel. The article’s guest kernel also isn’t Linux, though it seems to be aiming for Unix compatibility, e.g. ELF format)

Namespaces have a long history in operating systems, by the way: processes have had their own 'memory namespace' (aka virtual memory) in OSes since the 1960s. Modern Linux namespaces extend that concept to other aspects of the system like the file system, network, process ids, user ids, and more. (File system namespaces also have a long history in `chroot`). One kernel runs all these processes and implements the namespaces that keep them separate from each other. 'Containers', then, are a type of process whose namespaces are configured to make it seem like that process (or process tree) is the only one running on the system.

You could think of the difference between a kernel and a process in terms of the API that each one builds upon: a process builds upon both the CPU architecture and also API of the kernel that runs it (system calls like fork and open), while a kernel builds upon only the CPU architecture that runs it.

This particular kernel is also aware of the fact that it's running in a VM and is not designed to work on real CPU hardware; it makes "hypercalls" to the hypervisor as described in the article. Since virtualization is common, many real kernels including Linux have explicit support for being run efficiently in a VM, taking advantage of hardware acceleration and hypercalls where available. Most cloud computing environments run customer code in this type of virtual machine, not directly on real hardware.

This is hardware virtualization. Containers are OS "virtualization". They offer different levels of isolation and features.