在2026年欧洲嵌入式Linux开发者大会上，Linux内核开发者针对非对称多处理（AMP）基础组件进行了评估。结论指出，相关组件基础已较为稳固，具备开发基础，但贡献者覆盖面不足、测试碎片化问题亟待解决。本次评估源于将硬件自旋锁驱动合入主线内核的实践，促使全面审视AMP软件栈现状。演讲聚焦Linux生态，并推荐关注Zephyr、可信固件、设备树等其他相关会议内容。在AMP架构中，Linux应用处理器与实时内核同置于片上系统（SoC），通过邮箱、共享SRAM或DDR实现基础数据交互；更复杂的场景需对资源共享进行协同管理。Sang介绍的SCMI组件可协调Linux与专用处理器获取时钟等资源，其通信机制并不简单，双向架构需四组邮箱。固件实现方式存在差异，其Keystone示例中固件使用两组单向邮箱完成双向SCMI通信，但未设置通知确认路径。其他组件层分工明确，remoteproc负责固件加载、远端内核启停，通过配置共享内存与触发回调支持RPMsg通信；Virtio提出基于共享内存虚拟队列的开放通信标准，工作可处理时主动通知。调研显示，remoteproc核心代码提交量从Linux 5.0版本的175次增至约1550次，虽增长放缓，但邮箱相关提交及高贡献驱动仅近期出现。硬件自旋锁模块七年间提交量从19次增至30次，驱动数量稳定。尽管未断言组件存在缺陷，Sang呼吁更多人参与代码评审与测试，反思自旋锁驱动开发引发的文件与生命周期等维护负担，凸显降低开发阻力对复杂AMP系统的重要性。
--91likeyou---
Sang 对子系统代码提交情况的调研显示，remoteproc 核心代码提交量从 Linux 5.0 版本的 175 次增长至约 1550 次，不过在前期快速增长后增速有所放缓。邮箱相关提交与驱动是近期才增长起来，但贡献超过五个补丁的提交者仅约四人。硬件自旋锁模块情况尤为突出：约七年间核心提交量从 19 次增加到 30 次，而驱动数量基本没有变化。Sang 并未断言这些组件存在缺陷；他呼吁更多人参与代码评审和测试工作。
他的自旋锁驱动开发工作体现出了项目维护方面的负担：一个看似很小的改动最后延伸出头文件与生命周期问题，一项拟议的调试优化方案还遇到了已废弃 API 的问题。有时候仅仅为了测试一个驱动就需要修改固件和 U-Boot。OpenAMP 提供了构建说明和测试用例，但示例尚无法在所有受支持的板卡上统一运行。在 Sang 看来，降低这类开发阻力是支撑当下正在开发的更复杂 AMP 系统的关键。
查看英文原文：
🔥 热词：#linux 异步多进程基础已稳固,但仍需进一步测试和改进 · #linux异步io实现方式 · #linux异步io · #linux测试端口是否可达 · #linux搭建测试环境步骤 · #linux测试远程服务器端口是否开放 · #linux测试对方端口是否开放 · #Linux测试端口是否可以访问