一句话结论
Linux 非对称多处理基础组件已具备开发条件，但严重依赖小众维护者与碎片化测试，制约复杂系统落地。
关键要点
- 欧洲嵌入式 Linux 大会专家指出，Linux 邮箱驱动、remoteproc 及 SCMI 等组件基础稳固，可支撑开发，但需补充测试。
- 非对称多处理架构中，共享内存用于传输数据，邮箱负责触发信号，SCMI 协议用于 Linux 与系统控制处理器交互资源。
- 固件实现存在差异，部分双向通信架构因缺乏通知确认路径，导致仅使用单向邮箱时存在设计缺陷。
- 硬件自旋锁核心模块在七年间提交量仅从 19 次增至 30 次，驱动数量停滞，凸显核心基础设施发展缓慢。
- remoteproc 代码提交量在 Linux 5.0 后从 175 次激增至约 1550 次，但近期增速放缓且深度贡献者寥寥无几。
背景与事实
在 2026 年欧洲嵌入式 Linux 开发者大会上，Linux 内核开发者及 I2C 子系统维护者沃尔夫拉姆·桑（Wolfram Sang）对用于非对称多处理（AMP）的 Linux 基础组件进行了系统评估。此次审视的起因是他尝试将硬件自旋锁驱动合入主线内核的经历，该过程暴露了 AMP 软件栈中的多项复杂性与工程短板。他的演讲聚焦于 Linux 侧机制，涵盖了硬件通信、资源管理与进程控制等多个层面。
在典型的 AMP 硬件架构中，主应用处理器运行 Linux 系统，同时在与同一片上系统（SoC）内的轻量级实时内核协同工作。数据交换依赖于共享静态随机存储器（SRAM）或双倍数据率内存（DDR），而状态同步则依靠邮箱（Mailbox）机制发送“数据就绪”的门铃信号。这种通信架构在实际固件实现中往往比理论示意图更为复杂。例如，双向 SCMI（系统控制和管理接口）通信通常需要四个单向邮箱来分别处理请求、应答和通知确认。但在部分固件（如 Keystone 平台）中，开发者仅使用两个单向邮箱实现双向通信，导致没有预留通知响应的确认路径，这在架构设计上留下了盲区。
系统内的核心组件分工明确，形成了层级化的软件栈。位于底层的 remoteproc 框架负责远端内核固件的加载、启停控制及资源申请。当远端固件二进制文件声明了共享内存配置与回调函数后，即可支持 RPMsg 处理器间消息通信。在此之上，Virtio 技术定义了一种基于共享内存虚拟队列的开放通信标准。桑特别厘清了 RPMsg 与提议中的 virtio-over-message 机制的差异，后者试图通过消息通道承载虚拟 I/O 流量，但目前仍未进入 Linux 上游主线。为了便于开发者理解全局，他在演讲中建议听众结合大会期间发布的关于 Zephyr 实时操作系统、可信固件及设备树的配套讲解材料进行交叉学习。
对子系统代码演进情况的量化调研揭示了基础设施发展的不均衡。remoteproc 核心代码的提交量从 Linux 5.0 版本时期的 175 次，大幅增长至目前的约 1550 次，反映了早期生态的爆发式建设，但近期增速已趋于平缓。邮箱驱动模块的活跃度同样是近期才显著提升，然而在该领域提交了超过五个补丁的实质性贡献者仅有约四名工程师。相比之下，硬件自旋锁模块的演进尤为缓慢，在近七年的时间跨度内，其核心代码提交量仅从 19 次小幅增加到 30 次，且底层硬件驱动的覆盖数量基本处于停滞状态。基于这些客观数据，桑指出虽然基础组件在功能上可用，但生态圈的极度萎缩使得代码质量缺乏足够的第三方视角进行校验。
影响分析
对于从事嵌入式与汽车电子开发的中文技术从业者而言，这一现状意味着在构建复杂的异构计算系统时，必须将“测试碎片化”与“维护者集中度风险”纳入项目风险评估的核心维度。当前硬件自旋锁与底层邮箱驱动维护团队极度狭小，一旦项目团队发生人员变动或上游依赖库升级，极易引发难以追溯的兼容性问题。因此，企业开发团队在选型时不应直接盲目依赖上游默认配置，必须针对特定硬件平台建立独立且完备的测试用例库，覆盖固件通信断链、共享内存越界等极端场景。
此外，分析认为，在涉及实时控制资源调度的场景中，开发团队需对固件层的 SCMI 实现进行深度审计。既然上游固件在部分平台上缺少通知确认路径，若在此类架构上直接部署高可靠性的业务逻辑，当系统发生中断或异常时，极易造成死锁或资源状态不同步。从业者应在集成阶段强制要求供应商提供完整的通信拓扑图，并在应用层增加重传与超时兜底机制，以弥补底层硬件通信架构的设计缺陷。
适用边界
此评估结论主要适用于由 Linux 主导的复杂非对称多处理系统，其硬件架构通常涉及多核协同、跨核资源调度以及复杂的固件交互场景。对于纯单核对称多处理（SMP）架构，或者通过完整虚拟化层实现隔离的传统架构，上述关于邮箱碎片化与自旋锁驱动维护不足的问题不具备直接参考意义。同时，由于 virtio-over-message 传输机制尚未进入上游主线内核，依赖该协议进行开发的早期概念验证系统不受当前主线评估结论的覆盖。
孤本观察
纵观本次评估，将非对称多处理基础设施形容为“坚固但脆弱”十分贴切。底层框架虽然在 Linux 5.0 之后迎来了代码量的爆发式增长，但核心组件在长周期内依然呈现出“代码活跃度高而实际业务深度不足”的孤本特征。
这种“繁荣的停滞”现象反映出嵌入式开源生态的普遍痛点：庞大的框架代码掩盖了实际测试用例稀缺、硬件覆盖不完整的本质，导致技术栈的长期演进缺乏稳定的动力引擎。
常见问题
双向SCMI通信在部分固件实现中因邮箱数量不足导致了什么具体缺陷？
部分固件（如Keystone平台）仅使用两个单向邮箱实现双向通信，未预留通知响应的确认路径，导致缺乏通知确认机制，在架构设计上留下盲区。
remoteproc代码提交量在Linux 5.0前后发生了怎样的变化？
remoteproc核心代码提交量从Linux 5.0版本时期的175次激增至目前的约1550次，但近期增速已趋于平缓。
硬件自旋锁模块在过去七年内的代码演进和驱动覆盖状况如何？
在近七年时间跨度内，其核心代码提交量仅从19次小幅增加到30次，且底层硬件驱动的覆盖数量基本处于停滞状态。
邮箱驱动模块目前的深度贡献者规模大约是多少？
在邮箱驱动领域提交了超过五个补丁的实质性贡献者仅有约四名工程师。
此次评估结论不适用于哪两类硬件架构场景？
不适用于纯单核对称多处理（SMP）架构，也不适用于通过完整虚拟化层实现隔离的传统架构。
来源：InfoQ 中文 AI