Microkernel is an approach to design of operating system that gained popularity during 1980s. Under microkernel paradigma, the kernel itself only performs the bare minimum of tasks that cannot be done from userspace programs and need supervisor access to CPU. Everything else is implemented as server. Depending on use case and kernel, functions that normally reside within kernel, but are servers in microkernel paradigm are: filesystems, device drivers, network protocol stacks, etc. Despite performing critical tasks, servers are not granted unlimited access to hardware. This is exclusive ability of kernel itself. This limitation requires that servers are able to talk to each other. This is performed via kernel-provided message passing.
In CMRX, the kernel is tiny and only does the most essential jobs:
Everything else runs as separate, memory isolated process that offers its functions via RPC services.
In a traditional monolithic kernel design, if any privileged part misbehaves, everything can crash. Even if you use traditional partition-based memory protection a kernel-resident driver can still crash the whole system with just one wrong write because it has unlimited write access to all the memory. Consequences only depend on where exactly errorneous write happens. With a microkernel:
Security experts have a saying: “smaller is more secure.” CMRX’s kernel is so small that it’s much easier to verify it works correctly. This matters for safety-critical devices like medical equipment or industrial controls.
Everything else runs as regular process. Even device drivers are pushed out of the kernel. Another function commonly found inside kernel of other RTOS systems that is pushed out into userspace in CMRX are queues. In CMRX queues functions are provided by queue server
Since programs can’t directly access each other’s memory, they communicate through well-defined APIs (Application Programming Interfaces). APIs are accessible via RPC mechanism:
You can update one part without touching others. Need to fix the WiFi driver? Update just that program. The rest of your system keeps running with the old, working code.
Test each program separately. You don’t need to test every combination of every feature. Each program has clear boundaries and responsibilities.
Programs are self-contained with clear APIs. You can reuse a sensor program in different products without changes.
When something goes wrong, you know exactly which program caused it. No more hunting through millions of lines of code to find a bug.
People worry that microkernels are slow because programs have to send messages instead of directly calling functions. CMRX solves this by relying on remote procedure calling instead of message passing.
Message passing can be done fast if memory mapping unit is available, which allows zero-copy message reception. Microcontrollers are not equipped by mapping unit so copy is not avoidable. To avoid doing so CMRX performs remote procedure call which transfers calling thread into context of called process. This removes the need of copying data used for the call.