为什么还要做一个微内核？

微内核并不新鲜。三十年来，这个领域产生了大量针对性能、并行性、容错、安全性 甚至形式正确性的设计。但它始终没有给出一个在 20 KB 微控制器和多核服务器上 都诚实的统一抽象。

现有系统通常只选择光谱的一端：

• 云原生内核假设 cache、MMU、充足内存和对称核心；
• RTOS 假设单核、平坦地址空间和固定外设；
• 教学内核假设硬件不会被推到任何一个极端。

RME 试图找到真正的共同点——权能、线程、地址空间、中断——并围绕它构建一个 内核。它不是把云内核塞进 MCU，也不是让一个 RTOS 假装能调度数据中心。

三种超能力

超适应性

同一套抽象应当在微处理器和微控制器上都真正可用。在前者上，它应当比肩最先进的 云原生系统，同时提供更多并行性；在后者上，它应当比肩最先进的 RTOS，同时提供 更高的安全性和容错性。

对任何场景，设计问题是：如果完全为该场景从头构建一个系统，它会是什么样？ RME 能否做到同样好？ 如果不能，就存在设计优化的机会。

超复用性

所有组件——内核、驱动、中间件——都是解耦的，可以作为独立软件包部署。组件在 只有一个实例时消除函数指针，未使用的代码会从镜像中彻底裁掉。删除死代码不仅 是体积优化；它也移除了随之而来的漏洞。

超部署性

许多微内核是研究产物。RME 刻意拥抱工程上的困难：MCU 工具链、调试探针、工程 生成和生产部署中那些不优雅的部分。在微控制器上， RVM 负责工程生成和虚拟化层， 开发者拿到的是可用的 Keil 或 GCC 工程，而不是一堆移植笔记。

设计原则

项目从一组很小的信念出发：

• 理想比想法便宜，想法比代码便宜。
• 理论上实践与理论没有差别；实践上则有。
• 所有性能问题都来自某处不清晰的权责划分。
• 好的整体系统设计永远优于局部优化。
• 真正有用的适应性，优于虚假的演示性可移植。
• 如果你把某种底层硬件强行塞进一个抽象，那说明抽象是错的。

最后一条正是 RME 不假装 MPU 拥有 MMU、也不假装单核 MCU 具有缓存一致性的 原因。抽象只暴露硬件能够强制执行的机制，用户态策略再去组合它。

RME 不是什么

• 不是 POSIX/Linux 克隆。 系统调用刻意保持很小（34 个）且面向权能； POSIX 兼容不是设计目标。
• 不是完成态的多核操作系统。 x86-64 和部分应用处理器移植仍在进行中； 今天可交付、可测量的一侧是 MPU 微控制器。
• 不是多核 MCU 内核。 微控制器支持是单核的；多核 MCU 明确不在范围内。
• 不是单体发行版。 不存在一个包含所有驱动的“RME 镜像”；内核按配置裁剪， 组件在构建时选择。

支持平台页会明确区分已交付与路线图。没有测量过的特性，就会 被标成没有测量过。