Microkernels and containerization

[jamesaorson]

Monolithic OS

Monolithic software sucks. Period.

Microkernel OS

But a microkernel is not too foreign of a concept to developers anymore. The way that we use containerization to isolate development environments and mimic an OS on a different host OS is representative of what a microkernel is all about.

Benefits of Microkernel

• Each service in the microkernel is isolated
• Service failure means restarting a small isolated service rather than causing a whole system failure
• Updating and upgrading services can be done non-disruptively via red/black replacement

Microkernel Responsibilities

• Memory management
• Module loading and unloading
• Module Process scheduler (Schedules execution of processes within modules
• IPC between modules
• Port access

That's it...

Extraneous Responsibilities/Module Responsibilities

Microkernel Module Examples

• Filesystem
• IO
• Peripherals (mouse, keyboard)
• Network Manager
• UI
• User space package manager (Install shared objects, static and dynamic libraries, applications, and other microkernel modules)

Arguably, even basic IO could run as a module of the microkernel. Input and output need not be terminal-based, as a microkernel module could instead be sending and receiving IO over a network, or both

Module Inter-Dependency

Certain modules may depend on other modules, like mouse and keyboard may be dependent on physical IO, or network IO. These relationships would be a part of the module definition and the actual kernel of Panix would load and unload modules considering the module relationships.

Containerization

A Microkernel OS is simply a kind of containerization.

A Microkernel OS is running these "modules" as microservies in containers. The modules are given an allocation of memory from the Microkernel to play around in. Whatever one module does should never affect another module except via message passing delegated by the Microkernel itself.

Containerization as a compatibility layer

Modules can end up being of arbitrary complexity. Say we wanted to pull a Microsoft and allow a popular Linux distro to be run natively on Panix.

We would start with a module that translates known Linux system calls to equivalent Panix calls. With such a minimal Microkernel, most of the Linux calls will not actually map directly to a Panix call.

Example

We want to run a simple Linux program that creates a text file on a given path. The base Microkernel doesn't know about Filesystems, as that is the responsibility of a module. The translation module for Linux would have a requirement for a Filesystem module, delegating translated Filesystem calls to the Filesystem module.

Complications

The whole prospect of making an OS is complicated. It may sound like extra work to add all these extra modules to do our job, rather than directly place this functionality directly into the OS. That is the mistake of every Monolithic OS, saying that it would be easier in the short-term to bake functionality into the core.

We should instead focus on a competent, minimalist core that enables proper abstraction and extension. With this, we can achieve a highly customizable experience on Panix. Letting users and developers drop functionality in and out of the OS and architect their own unique platform.

[Kfeavel]

When the microkernel loads modules, for example the compatibility layer, how does that work? Do the modules register "syscalls" with the microkernel which then redirects to the proper function? If not, how do system calls get rerouted to their proper, non-kernel destination?

[jamesaorson]

Not all modules are translating calls and acting as compatibility layers. I am saying that the intense isolation of modules better facilitates something like a compatibility layer as a module.

How the compatibility layer works is a different topic as it is its own thing.

A normal module can be thought of similarly to systemd services in that they are essentially system-level applications rather than user-level applications.

In thinking about how the compatibility layer would work, say the linux compatibility module wishes to open a file. The compatibility module would know how that syscall maps to a set of calls either to the microkernel itself, or to appropriate modules. So the Linux compatibility module would call off to something like an Ext4 Filesystem module to "open a file" in the way that preserves compatibility with that Linux application.

[micahswitzer]

That's the nice thing about microkernels, they have very few system calls. 95% of the time you'll be using the "send IPC message" syscall to communicate with other modules. In this situation the kernel only acts as a broker that passes messages around. Whether or not modules have to register which messages they support with the kernel is a design decision that needs to be made, but generally I don't think that's something that most microkernels require.

This webpage might help you understand the various kinds of IPC present in a microkernel as well as how they might be implemented:
https://web.archive.org/web/20140803112320/http://i30www.ira.uka.de/~neider/edu/mkc/mkc.html#ch_IPCFunctionality