Evaluating Revera

This directory evaluates Revera against the criteria an engineer weighs when choosing a real-time operating system — determinism, footprint, multicore, isolation, safety, tooling, licensing. It is written for a prospective adopter deciding whether Revera fits a specific project.

How to read each axis. Every file follows the same shape: the generic criterion (what to look for), how Revera answers it (honest prose), a feature → how-to table (each capability, the config knob that turns it on, the exact API symbols to call, and the architectures it works on), and limits & roadmap. The tables answer “I know Revera does X — how do I use it?” with API pointers; follow them to the API reference for full detail. Where Revera is minimal or a feature lives only in the project’s history, the axis says so plainly — that honesty is the point.

The differentiator

  • Memory Protection & Isolation — hardware-enforced per-thread and per-island memory fencing that binds even the kernel. Revera’s headline; start here.

Core kernel

Portability, configuration, ergonomics

Product & assurance


Per-feature, per-architecture maturity (proven-on-hardware vs emulator vs implemented) lives in the readiness dashboard. This evaluation is a work-in-progress adopter’s view; it is reconciled against the shipped 0.1.0 product, not a marketing overlay.