Microkernel Architecture

What is a Microkernel?

Think of a traditional operating system like a big factory where everything happens in one huge building. A microkernel is like having a small management office that coordinates many smaller, specialized workshops.

In CMRX, the microkernel is tiny and only does the most essential jobs:

• Managing programs (processes)
• Letting programs talk to each other safely
• Handling memory protection
• Basic scheduling (deciding which program runs when)

Everything else runs as separate, protected programs.

Why Use a Microkernel Design?

Better Security

In a traditional system, if any part breaks, everything can crash. Even if you use traditional partition-based memory protection a kernel-resident driver can still crash the kernel. With a microkernel:

• The core system is very small and simple (less likely to have bugs)
• Each service runs separately (problems don’t spread)
• Even device drivers can’t crash the main system as they run as userspace processes

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 Separately

All other services run as regular processes:

• File systems
• Network stacks
• Device drivers
• User interfaces
• Custom applications
• Non-essential system services (such as queues)

This means even critical services like drivers are protected from each other. The fact that these services are running separately means they can easily be removed if they are not needed.

Communication Through APIs

Since programs can’t directly access each other’s memory, they communicate through well-defined APIs (Application Programming Interfaces). APIs are used everywhere:

• When userspace process is requesting operating system service via syscall
• When userspace process wants to call procedure provided by another process
• When userspace process talks to driver
• When drivers talk to each other

Technical Advantages

Modularity

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.

Easier Testing

Test each program separately. You don’t need to test every combination of every feature. Each program has clear boundaries and responsibilities.

Reusability

Programs are self-contained with clear APIs. You can reuse a sensor program in different products without changes.

Easier Debugging

When something goes wrong, you know exactly which program caused it. No more hunting through millions of lines of code to find a bug.

What Makes CMRX Different

Compared to Traditional RTOSes

Traditional RTOS (like FreeRTOS):

• Everything runs in one memory space (or limited separation is manually configured)
• Shared data structures everywhere
• One bug can crash everything
• Hard to isolate problems

CMRX:

• Each process isolated in its own space
• Drivers are isolated in similar way as processes
• Communication only through well-defined APIs
• Problems contained to one process
• Easy to identify and fix issues

Compared to Full-Scale Microkernels

Full-scale microkernels:

• Consume much more system resources
• Require presence of memory mapping unit

CMRX:

• Can run with as low as 2kB of RAM
• Requires presence of memory protection unit

Performance Considerations

Overhead is Minimal

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.