Kernel Design

RME is a capability-based microkernel. The kernel provides mechanism; policy — scheduling, paging, device management, virtualization — is composed at user level from capabilities. This page walks through the mechanisms.

Capabilities

A capability is an unforgeable token that names a resource and carries the rights to operate on it. RME capabilities follow three rules:

1. they cannot be modified at user level;
2. they can only move between processes through well-defined interfaces;
3. they are only granted to processes that may operate on the object.

The design uses a two-level capability table, which bounds lookup to a depth of 2 (in seL4 terms, CSpace depth 2). Capabilities are uniformly sized and aligned to an 8-word boundary, so the table can be managed without variable allocations on a racey multi-core machine. Certain calls operate on several capabilities in one transaction, amortising the lookup cost.

Processholds one capability table

→

Level 1fixed, uniform slots

→

Level 2object capabilities

→

Objectthread, page table, endpoint, IRQ

The protection domain belongs to the process, not the thread: a process is a capability table plus a page table, shared by every thread inside it. Threads do not carry separate capability spaces, which keeps context switches cheap and the authority model explicit.

Scheduling

The kernel makes preemption decisions; the user level manages execution budgets.

• Every thread carries a budget. The in-kernel scheduler is a simple FPRR (fixed-priority round-robin) mechanism that only expends budget; it never replenishes or revokes it.
• Replenishment, revocation and hierarchical policies are user-level decisions. The fast path therefore never calls a scheduler thread: a preemption decision is one bounded in-kernel comparison.
• On microcontrollers this gives the shortest possible latency with basic budget control. On application processors the priorities can be arranged so that the in-kernel FPRR is bypassed and arbitrarily complex user-level MCS policies take over, at the cost of an extra context switch — acceptable when the pipeline is superscalar and bounded interference matters more than the last microsecond.

This split is why RME can be both an RTOS-grade kernel and a substrate for mixed-criticality scheduling without embedding a policy engine in the kernel.

Memory

Kernel objects live in a kernel object table (KOT). Its bitmap has a 32-byte granularity, so object boundaries are compile-time known and the kernel never needs a general-purpose allocator on the hot path.

• Address-space management can stay in the kernel, or be delegated to a trusted user-level page server through page-table capabilities.
• The kernel can be configured to remove in-kernel address-space management entirely, leaving a pure capability and scheduling core.
• Memory is retyped and delegated through page-table capabilities; the kernel enforces the rights, the user-level server decides the layout.

Communication

RME has two communication primitives:

Synchronous invocation

A synchronous invocation migrates the client thread into the server. The client's thread executes the server's code using the client's own time budget. There is no separate server thread, no scheduler invocation and no priority inversion introduced by a server loop. The server returns with RME_SVC_INV_RET.

Asynchronous signals

A signal endpoint behaves as a counting semaphore per processor. Sending and receiving are bounded operations on endpoint capabilities; interrupt signals use the same mechanism, which is why the measured interrupt signal latency is in the same range as intra-process signalling.

User-level IPIs let components on different cores signal each other without routing every notification through a global kernel lock.

Virtualization

RME virtualizes by giving each vCPU two threads:

1. a user-level vCPU thread that executes guest code;
2. a higher-priority vector thread that handles traps and interrupts for that vCPU.

This is type-II paravirtualization: the guest's privileged operations are turned into invocations of the vCPU monitor. On hardware with virtualization extensions the same structure can host a type-I hypervisor. Full virtualization is deliberately limited to platforms where the hardware/software interface has a de-facto standard; the project does not attempt shadow page tables and dynamic binary translation on every architecture.

When used to virtualize an RTOS, the measured overhead can be as low as 6%.

Parallelism and kernel calls

The kernel is designed for many cores without coarse locks:

• lock-free data structures and atomic operations on the hot paths;
• every system call is a bounded-time transaction, not a sequence of independently locked steps;
• objects are reclaimed with quiescence-based RT-SMR rather than stop-the-world epochs;
• threads are explicitly bound to processors, so the scheduler does not chase migrating run queues.

The kernel itself is non-preemptible, has one kernel stack per CPU, and avoids unbounded loops and recursion. There are 34 kernel calls (0–33; 34–63 are reserved), grouped into invocation, signal, thread, capability, page-table, process and endpoint operations.

Group	Calls
Invocation / signal	activate, return, send, receive
Threads	create, delete, execute, switch, priority, time transfer, bind
Capabilities	create, delete, freeze, add, remove
Page tables	create, delete, add, remove, construct, destruct
Processes	create, delete, set capability table, set page table
Endpoints	create/delete signal endpoints and invocation ports

A deliberately small kernel

The architecture-independent core is one C file of roughly 8,000 lines. The kernel exposes mechanism, not servers: a page server, a scheduler, a vCPU monitor and the drivers are ordinary user-level components that hold capabilities. That is what makes the same kernel configurable from a 64 KB MCU to a many-core machine — and what makes the security argument reviewable.