Microkernels and containerization #165
Replies: 1 comment 2 replies
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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: |
Beta Was this translation helpful? Give feedback.
-
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
Microkernel Responsibilities
That's it...
Extraneous Responsibilities/Module Responsibilities
Microkernel Module Examples
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.
Beta Was this translation helpful? Give feedback.
All reactions