Linux 异步多进程基础已稳固，但仍需进一步测试

在 2026 年欧洲嵌入式 Linux 开发者大会上，Linux 内核开发者、Linux I2C 子系统维护者 Wolfram Sang 探讨了用于非对称多处理（AMP）的 Linux 基础组件。他的评估结论是：这些组件基础稳固，可以在此之上进行开发，但贡献者覆盖面不足、测试碎片化的问题亟待重视。 他的演讲源于一次将硬件自旋锁驱动合入主线内核的尝试，这项工作促使他重新审视整个 AMP 软件栈的整体状况。演讲重点聚焦 Linux 一侧，并推荐听众参考其他关于 Zephyr、可信固件和设备树的会议演讲。 在基础的 AMP 系统中，Linux 应用处理器与一个小型实时内核运行在同一颗片上系统（SoC）内。邮箱用于发出“信息已就绪”的信号；共享静态随机存储器（SRAM）或者双倍数据率内存（DDR）用于存放数据。更复杂的系统还需要对共享资源的所有权进行协同管理。Sang 介绍了 SCMI，可以让 Linux 与专用系统控制处理器交互时钟等资源，而不是由 Linux 独自管理所有资源。 这种通信方式并不像邮箱示意图看上去的那么简单。门铃信号通常是单向的。Sang 演示了两个单向邮箱如何构成一条请求和应答通道，而一个完整双向 SCMI 通信架构需要四个邮箱。固件可能会采用不同的实现方式：在他的 Keystone 示例中，现有固件使用两个单向邮箱来实现双向 SCMI 通信，因此没有为通知预留相应的确认路径。 其他组件层各司其职。remoteproc 负责加载固件、启停远端内核；它的固件二进制文件可以描述自身所需资源。只要配置好共享内存以及用于触发对端的驱动回调函数，remoteproc 就可以支持 RPMsg 消息通信。Virtio 定义了一种使用共享内存虚拟队列的开放通信标准，并在有工作可处理时发出通知。Sang 解释了 RPMsg（用于处理器间通信）与提议中的 virtio-over-message 传输机制（后者将通过消息通道承载 virtio 流量，目前尚未进入上游）的区别。 Sang 对子系统代码提交情况的调研显示，remoteproc 核心代码提交量从 Linux 5.0 版本的 175 次增长至约 1550 次，不过在前期快速增长后增速有所放缓。邮箱相关提交与驱动是近期才增长起来，但贡献超过五个补丁的提交者仅约四人。硬件自旋锁模块情况尤为突出：约七年间核心提交量从 19 次增加到 30 次，而驱动数量基本没有变化。Sang 并未断言这些组件存在缺陷；他呼吁更多人参与代码评审和测试工作。 他的自旋锁驱动开发工作体现出了项目维护方面的负担：一个看似很小的改动最后延伸出头文件与生命周期问题，一项拟议的调试优化方案还遇到了已废弃 API 的问题。有时候仅仅为了测试一个驱动就需要修改固件和 U-Boot。OpenAMP 提供了构建说明和测试用例，但示例尚无法在所有受支持的板卡上统一运行。在 Sang 看来，降低这类开发阻力是支撑当下正在开发的更复杂 AMP 系统的关键。 查看英文原文： https://www.infoq.com/news/2026/10/linux-amp-analysis/ "