Why Another Microkernel?

Microkernels are not new. For thirty years the field has produced designs optimised for performance, parallelism, fault tolerance, security and even formal correctness. What it has not produced is a single abstraction that is honest on both a 20 KB microcontroller and a many-core server.

Existing systems typically choose one side of the spectrum:

• cloud-native kernels assume caches, MMUs, plentiful memory and symmetric cores;
• RTOSes assume a single core, a flat address space and a fixed set of peripherals;
• teaching kernels assume the hardware will not be pushed to either extreme.

RME is an attempt to find the actual common ground — capabilities, threads, address spaces, interrupts — and to build one kernel around it. Not a cloud kernel squeezed onto an MCU, and not an RTOS pretending it can schedule a datacenter.

The three hypers

Hyperadaptability

The same abstraction should be practically usable on microprocessors and microcontrollers. On the former it should keep up with state-of-the-art cloud-native systems while offering more parallelism; on the latter it should keep up with state-of-the-art RTOSes while offering more security and fault tolerance.

For any scenario, the design question is: what would a system built entirely from scratch for this case look like, and can RME be as good as that? If not, there is a design opportunity.

Hyperreusability

Every component — kernel, driver, middleware — is decoupled and can be deployed as a standalone package. The components are written so that function pointers disappear when only one instance exists, and unused code is stripped from the image entirely. Removing dead code is not only a size optimisation; it removes the vulnerabilities that would have travelled with it.

Hyperdeployability

Many microkernels are research artefacts. RME deliberately embraces the engineering difficulties: MCU toolchains, debug probes, project generation and the awkward parts of production deployment. On microcontrollers, RVM does the project generation and hypervisor work, so the developer gets a working Keil or GCC project rather than a pile of porting notes.

Design principles

The project starts from a small set of beliefs:

• Ideals are cheaper than ideas, ideas are cheaper than code.
• In theory there is no difference between practice and theory; in practice there is.
• All performance issues are caused by an obscure division of rights and duties.
• Good overall system design is preferred over peephole optimisation.
• True useful adaptability is better than false demonstrational portability.
• If you coerce some underlying hardware into an abstraction, you have the wrong abstraction.

The last one is the reason RME does not pretend that an MPU has an MMU, or that a single-core MCU has cache coherency. The abstraction exposes what the hardware can enforce, and the user-level policy composes it.

What RME is not

• Not a POSIX/Linux clone. The system-call set is deliberately small (34 calls) and capability-oriented; POSIX compatibility is not a design goal.
• Not a finished many-core operating system. The x86-64 and some application-processor ports are work in progress; the measured, deliverable side today is the MPU microcontroller target.
• Not a multi-core MCU kernel. Microcontroller support is single-core; multi-core MCUs are explicitly out of scope for now.
• Not a monolithic distribution. There is no single "RME image" that contains every driver; the kernel is configured and components are selected at build time.

The platforms page keeps the delivered/roadmap distinction explicit. If a feature is not measured, it is labelled as such.