RIOT 子系统分工与维护者指南从 SUBSYSTEMS.md 读懂 RIOT 的贡献路径与模块版图【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOTRIOT 是一个面向 IoT 的实时操作系统The friendly OS for IoT其代码库覆盖从 AVR/Cortex-M/RISC-V 等 CPU 支持、外围驱动到 GNRC 网络栈与构建系统的庞大版图。对于想提交 Issue 或 Pull Request 的贡献者来说SUBSYSTEMS.md 是定位该找谁的权威入口它按 CPU、硬件模块、内核、系统库、网络、构建系统、测试等维度列出了各子系统的维护者。读完本文你将掌握 RIOT 子系统的完整分工版图、每个子系统对应的仓库源码位置以及 SUBSYSTEMS.md 与 CODEOWNERS 两套负责人机制如何协同工作从而在贡献代码时准确找到评审人。一、SUBSYSTEMS.md 的作用与贡献流程SUBSYSTEMS.md 的核心定位非常明确它是 RIOT 各子系统subsystem维护者名单的总览。文档开宗明义地给出了贡献规则当你提交 Issue 或 Pull Request 时请在 Issue 跟踪器中把受影响模块的维护者之一指定为 assignee。维护者要么亲自修复/合并该 Issue/PR要么把它转派给有能力的开发者。文档同时提示了两条重要边界情况一名开发者可能同时维护多个子系统例如 Kaspar Schleiser 既负责内核 core又负责构建系统、测试/CI 与高层定时器 API一个 Issue 可能影响多个模块因此可能需要指派多个维护者。这种按子系统划分责任田的机制避免了大型开源项目中问题无人认领的困境也让社区能够保证每个模块都有长期熟悉该代码的人把关。二、子系统分工总览以下是 SUBSYSTEMS.md 中列出的完整分工结构按文档原有层级整理2.1 CPU 支持子系统维护者ESP32、ESP8266文档中暂无署名可结合 CODEOWNERS 查找MSP430Marian Buschsieweke (maribu)ARM7Marian Buschsieweke (maribu)ARM Cortex-M — Atmel SAM0 系列SAM D1x/D2x、L1x、L2x、D5xBenjamin Valentin (benpicco)、Dylan Laduranty (dylad)Atmel AVRAtmegaMarian Buschsieweke (maribu)Native — ZEP 无线电仿真与 ZEP dispatcherBenjamin Valentin (benpicco)2.2 硬件模块子系统维护者网络设备 — IEEE 802.15.4 / NRF802154 / CC2538 / KW2XRF / MRF24J40 / AT86RF2XXJosé I. Álamos (jia200x)AT86RF215Benjamin Valentin (benpicco)LoRaJosé I. Álamos (jia200x)CC110XMarian Buschsieweke (maribu)外设PeripheralsMarian Buschsieweke (maribu)2.3 内核core整个内核core由Kaspar Schleiser (kaspar030)负责。2.4 系统库子系统维护者高层定时器 APIxtimer、ztimerKaspar Schleiser (kaspar030)MTD 子系统Benjamin Valentin (benpicco)USB 支持Dylan Laduranty (dylad)Rust 支持Christian Amsüss (chrysn)、Kaspar Schleiser (kaspar030)C 支持Marian Buschsieweke (maribu)Power Management、File Systems、POSIX 支持、脚本语言、Crypto 等条目在文档中暂未列出具体维护者遇到这些领域的贡献建议通过 CODEOWNERS 中对应的路径规则定位负责人见第四节。2.5 网络子系统维护者网络栈 — GNRC / 6LowPAN / IPv6 / UDPMartine S. Lenders (miri64)IPv6 — Auto-SubnettingBenjamin Valentin (benpicco)GNRC — NetifJosé I. Álamos (jia200x)网络栈 — OpenThread / OpenWSNJosé I. Álamos (jia200x)网络栈 — LWIPMartine S. Lenders (miri64)物理/链路层 — LoRaWANJosé I. Álamos (jia200x)物理/链路层 — IEEE 802.15.4José I. Álamos (jia200x)接口 — Sock / Netif / Netdev分别由 miri64、jia200x、jia200x 负责应用协议 — CoAPnanoCoAPBenjamin Valentin (benpicco)其他 — DTLSMartine S. Lenders (miri64)2.6 构建系统、文档与测试/CI构建系统Build SystemKaspar Schleiser (kaspar030)测试/CITesting/CIKaspar Schleiser (kaspar030)文档Documentation条目暂未署名三、子系统与仓库源码目录的对应关系理解维护者分工的最佳方式是把 SUBSYSTEMS.md 中的每个子系统映射回仓库里真实的代码目录。以下映射均可在当前仓库中直接打开查证。3.1 CPU 子系统 →cpu/RIOT 的每个 CPU 架构支持都位于 cpu/ 目录下与 SUBSYSTEMS.md 的划分一一对应Atmel AVRAtmegacpu/atmega_common/、cpu/atmega328p/、cpu/atmega2560/ 等公共抽象层在cpu/atmega_commonARM7cpu/arm7_common/ 与 cpu/arm7tdmi_gba/Game Boy Advance 移植ARM Cortex-M / Atmel SAM0 线cpu/cortexm_common/ 提供 Cortex-M 公共实现cpu/sam0_common/、cpu/samd21/、cpu/samd5x/、cpu/saml21/ 对应 SUBSYSTEMS.md 中提到的 SAM D1x/D2x、L1x、L2x、D5x 系列MSP430cpu/msp430/Native含 ZEP 无线电仿真cpu/native/ZEP dispatcher 用于在 native 平台上仿真 802.15.4 网络此外还有ESP32/ESP8266cpu/esp32/、cpu/esp8266/、STM32cpu/stm32/、nRF 系列cpu/nrf52/、cpu/nrf53/、RISC-Vcpu/riscv_common/、RP2350cpu/rp2350_arm/、cpu/rp2350_riscv/等。值得注意SUBSYSTEMS.md 中 ESP32/ESP8266 条目为空但 CODEOWNERS 中明确将/cpu/esp*/与/boards/esp*/指派给 gschorcht/boards/common/esp*/同样归其负责——这正是两套机制互补的典型案例。3.2 硬件模块 →drivers/SUBSYSTEMS.md 中Hardware modules部分列出的无线电与外设驱动全部位于 drivers/ 下802.15.4 无线电drivers/at86rf2xx/jia200x 负责的主驱动、drivers/at86rf215/benpicco 单独负责CODEOWNERS 中/drivers/at86rf215/ benpicco可印证LoRa 前端drivers/sx126x/、drivers/sx127x/、drivers/sx1280/CC110Xmaribudrivers/cc110x/ 及公共层 drivers/cc1xxx_common/KW2XRF / MRF24J40drivers/kw2xrf/、drivers/mrf24j40/NRF802154作为 nRF52 板上的无线电实现在 cpu/nrf52/radio/ 下CODEOWNERS 中/cpu/nrf52/radio/nrf802154/ bergzand jia200x体现了跨子系统的联合维护外设抽象层Peripheralsmaribudrivers/periph_common/ 提供 GPIO、UART、SPI、I2C、定时器、RTC 等通用实现公共头文件位于 drivers/include/periph/SAUL 传感器注册框架drivers/saul/ 汇聚了数百种传感器驱动的适配代码。3.3 内核core→core/SUBSYSTEMS.md 中Kernel (core)由 kaspar030 负责与 CODEOWNERS 中/core/ kaspar030一致。内核源码全部位于 core/ 目录从源码文件可以直接看出 RIOT 内核的构成core/thread.c、core/thread_flags.c、core/thread_flags_group.c线程创建与线程标志机制core/sched.c调度器实现core/msg.c、core/msg_bus.c线程间消息传递core/mutex.c、core/mbox.c、core/cond.c互斥锁、邮箱、条件变量等同步原语公共 API 头文件位于 core/include/如thread.h、sched.h、msg.h、mutex.h等。3.4 系统库 →sys/SUBSYSTEMS.md 的System libraries各条目在仓库中的落点xtimer / ztimersys/xtimer/、sys/ztimer/公共头文件 sys/include/ztimer.h。CODEOWNERS 进一步细化到/sys/ztimer/ kaspar030 bergzand、/sys/xtimer/ kaspar030 MichelRottleuthner可见实际评审由多人协作完成Power Managementsys/pm_layered/分层电源管理CODEOWNERS 指派 kaspar030MTD 子系统drivers/mtd/ 为核心配套 drivers/mtd_emulated/RAM 模拟、drivers/mtd_sdcard/、drivers/mtd_sdmmc/、drivers/mtd_spi_nor/、drivers/mtd_flashpage/、drivers/mtd_mapper/File Systemssys/fs/ 与 sys/vfs/ 提供文件系统与虚拟文件系统框架具体文件系统实现则以 pkg 形式引入如 pkg/littlefs/、pkg/spiffs/、pkg/fatfs/USB 支持sys/usb/dylad 牵头CODEOWNERS 中还包含 bergzand 与 aabadie配套驱动位于 drivers/usbdev_mock/ 等POSIX 支持sys/posix/Rust 支持仓库根部的Cargo.toml/Cargo.lock等CODEOWNERS 中Cargo.* chrysn、*.rs chrysn以及 sys/rust_riotmodules/ 等模块桥接代码C 支持sys/cpp11-compat/、sys/cpp_new_delete/编码规范见仓库根部的 CODING_CONVENTIONS_C.mdCryptosys/crypto/、sys/psa_crypto/CODEOWNERS 指派 mguetschow、sys/hashes/以及 pkg 中的 pkg/mbedtls/、pkg/wolfssl/ 等第三方库。3.5 网络子系统 →sys/net/与pkg/网络是 RIOT 最庞大的子系统SUBSYSTEMS.md 的层级划分与源码目录结构高度吻合GNRC 网络栈miri64sys/net/gnrc/ 下按层组织——sys/net/gnrc/link_layer/链路层含 6LowPAN、sys/net/gnrc/network_layer/IPv6 等网络层、sys/net/gnrc/transport_layer/UDP/TCP、sys/net/gnrc/routing/rpl/RPL 路由协议Netif / Netdev / Sock 接口sys/net/netif/、sys/net/gnrc/netif/、sys/net/gnrc/sock/netdev 驱动接口头文件为 drivers/include/net/netdev.hLoRaWAN 链路层sys/net/gnrc/link_layer/lorawan/配合 LoRa 区域/MAC 协议栈 pkg/semtech-loramac/CODEOWNERS 指派 aabadie 与 jia200x应用协议nanoCoAP 位于 sys/net/application_layer/nanocoap/gcoap 位于 sys/net/application_layer/gcoap/MQTT 由 pkg/paho-mqtt/ 提供LWM2M 由 pkg/wakaama/ 提供其他网络栈LWIP 在 pkg/lwip/、OpenThread 在 pkg/openthread/、OpenWSN 在 pkg/openwsn/DTLSpkg/tinydtls/CODEOWNERS 指派 leandrolanzieri。3.6 构建系统、测试与 CI构建系统kaspar030仓库根部的 Makefile、Makefile.base 与 makefiles/ 目录其中vars.inc.mk、application.inc.mk、dependency_resolution.inc.mk等文件定义了 RIOT 基于 GNU Make 的模块化构建机制测试/CIkaspar030tests/ 目录包含数千个针对 CPU、驱动、网络栈、pkg 的测试工程CI 配置可通过 makefiles/tests/ 与仓库中的.ci文件了解fuzzing 目标位于 fuzzing/。四、双重机制SUBSYSTEMS.md 与 CODEOWNERS 如何协同SUBSYSTEMS.md 面向人——用自然语言描述职责领域而仓库根部的 CODEOWNERS 面向自动化——用 glob 路径模式为 GitHub 自动指派代码评审autoreview。两者互补且 CODEOWNERS 的规则更细粒度。CODEOWNERS 文件头部说明了其核心规则Order is important; for each modified file, thelast matching pattern takes the most precedence顺序重要对每个被修改的文件最后一个匹配的模式拥有最高优先级。举几个从 CODEOWNERS 中摘取的典型规则可以看到它们如何把 SUBSYSTEMS.md 的分工落到文件级别CODEOWNERS 规则对应 SUBSYSTEMS.md 条目/core/ kaspar030Kernel (core)/cpu/msp430*/ kaspar030 gschorchtMSP430maribu 之外还有联合维护者/cpu/atmega*/ kYc0o maribuAtmel AVRAtmega/cpu/sam0_common/ benpicco dylad keestuxAtmel SAM0 线/drivers/at86rf2xx/ jia200x miri64AT86RF2XX/drivers/cc110x/ maribuCC110X/sys/ztimer/ kaspar030 bergzandxtimer、ztimer/sys/usb/ bergzand dylad aabadieUSB 支持/sys/net/ miri64GNRC 网络栈兜底规则宽泛匹配/sys/net/gnrc/routing/rpl/ emmanuelsearchRPL细粒度规则覆盖上面的兜底规则Kconfig leandrolanzieri jia200x MrKevinWeiss任何 Kconfig 变更都会通知三位负责人从上表可以读出这套机制的两个设计要点一是兜底 细化——/sys/net/ miri64作为宽匹配兜底而/sys/net/gnrc/routing/rpl/这样的窄模式按最后匹配优先原则覆盖它确保 RPL 的变更能被专门的负责人看到二是多维护者冗余——关键路径通常列出 23 名负责人避免单点阻塞。五、维护者的工作流MAINTAINING.md 中的评审准则找到维护者只是第一步维护者拿到 Issue/PR 后如何工作则由 MAINTAINING.md 定义。该文档给出了 RIOT 维护者的完整评审基线核心分为技术准则与非技术准则两部分。技术准则按效率优先排序前一步失败则后续步骤作废审查基本问题PR 的理由是否成立、问题是否清晰、方案是否足够简单但不再更简单、PR 体量是否可控应是一个单一可解释的变更、提交历史是否干净、是否有清晰的测试说明、代码能否编译运行、是否尊重原作者版权、是否与既有 PR 重复审查代码设计检查代码重复、内存占用可对比构建体积、所有代码路径、API 一致性、错误处理一致性、变量作用域、语法/语义/逻辑错误并可借助dist/tools/coccinelle中的 Coccinelle 脚本辅助但不能替代人工审查测试 PR在native平台以及若干选定板卡上运行测试验证行为或给出清晰合理的跳过理由对照编码规范审查检查是否符合 CODING_CONVENTIONS.md可借助根目录的 uncrustify-riot.cfg 运行 Uncrustify 辅助检查审查文档确保模块级文档充分、函数级文档完整、难懂处有注释、文档无语法拼写错误。非技术准则同样重要维护者应对贡献者保持响应哪怕只是先回复会在合适时间评审、乐于提供精确有帮助的建议、尊重原作者的设计选择并始终遵循行为准则。关于维护者之间的协作MAINTAINING.md 还规定了部分评审Partial review机制——维护者可以只评审部分章节此时不应给出 approve 而应给出口头 ACK 并说明评审范围可用 Reviewed: 系列标签标记已处理/已跳过的章节全部标签齐备后才能批准合并维护者只能给自己指派 PR不能替他人指派。发布与回迁Backports流程方面每次正式发布前会宣布软冻结仅允许合并影响较小的 PR与硬冻结release 分支创建后解除 master 分支合并限制两个特性冻结期。release 分支建立后不再接受新功能回迁只接受 bug 修复或对尚未达到成熟度特性的回滚较大变更含任何 revert应在 PR 打开 48 小时后才可合并且至少需要两个 ACK安全相关的回迁可以跳过公告流程只要凑齐两个 ACK 即可合并。六、贡献者实操建议结合 SUBSYSTEMS.md、CODEOWNERS 与仓库目录结构推荐以下三步定位法确定变更所属子系统先想清楚你的改动落在 CPUcpu/、驱动drivers/、内核core/、系统库sys/、网络sys/net/、pkg/还是构建系统makefiles/再到 SUBSYSTEMS.md 对应小节查找维护者姓名条目为空时转向 CODEOWNERS若 SUBSYSTEMS.md 中该条目没有署名如 ESP32、Power Management、File Systems打开 CODEOWNERS按最后匹配优先的规则查找覆盖你改动路径的 glob 模式其中列出的维护者即评审人在 Issue/PR 中指定 assignee 并附测试说明按 SUBSYSTEMS.md 的要求指派对应模块维护者参照 MAINTAINING.md 技术准则第 1.8 条PR 描述中应包含清晰的测试指引哪些平台、哪些测试命令这会显著加快评审。最后需要提醒维护者名单与 CODEOWNERS 规则都是随项目演进的活文档本文呈现的信息以当前仓库快照为准如果你准备提交贡献请以仓库中 SUBSYSTEMS.md 与 CODEOWNERS 的最新内容为准二者共同构成了 RIOT 友好贡献文化的制度基础——每个模块都有人负责每个贡献都能找到路径。【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 2:09:10 · 阅读 1.2k RIOT 子系统分工与维护者指南：从 SUBSYSTEMS.md 读懂 RIOT 的贡献路径与模块版图
RIOT 子系统分工与维护者指南从 SUBSYSTEMS.md 读懂 RIOT 的贡献路径与模块版图【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOTRIOT 是一个面向 IoT 的实时操作系统The friendly OS for IoT其代码库覆盖从 AVR/Cortex-M/RISC-V 等 CPU 支持、外围驱动到 GNRC 网络栈与构建系统的庞大版图。对于想提交 Issue 或 Pull Request 的贡献者来说SUBSYSTEMS.md 是定位该找谁的权威入口它按 CPU、硬件模块、内核、系统库、网络、构建系统、测试等维度列出了各子系统的维护者。读完本文你将掌握 RIOT 子系统的完整分工版图、每个子系统对应的仓库源码位置以及 SUBSYSTEMS.md 与 CODEOWNERS 两套负责人机制如何协同工作从而在贡献代码时准确找到评审人。一、SUBSYSTEMS.md 的作用与贡献流程SUBSYSTEMS.md 的核心定位非常明确它是 RIOT 各子系统subsystem维护者名单的总览。文档开宗明义地给出了贡献规则当你提交 Issue 或 Pull Request 时请在 Issue 跟踪器中把受影响模块的维护者之一指定为 assignee。维护者要么亲自修复/合并该 Issue/PR要么把它转派给有能力的开发者。文档同时提示了两条重要边界情况一名开发者可能同时维护多个子系统例如 Kaspar Schleiser 既负责内核 core又负责构建系统、测试/CI 与高层定时器 API一个 Issue 可能影响多个模块因此可能需要指派多个维护者。这种按子系统划分责任田的机制避免了大型开源项目中问题无人认领的困境也让社区能够保证每个模块都有长期熟悉该代码的人把关。二、子系统分工总览以下是 SUBSYSTEMS.md 中列出的完整分工结构按文档原有层级整理2.1 CPU 支持子系统维护者ESP32、ESP8266文档中暂无署名可结合 CODEOWNERS 查找MSP430Marian Buschsieweke (maribu)ARM7Marian Buschsieweke (maribu)ARM Cortex-M — Atmel SAM0 系列SAM D1x/D2x、L1x、L2x、D5xBenjamin Valentin (benpicco)、Dylan Laduranty (dylad)Atmel AVRAtmegaMarian Buschsieweke (maribu)Native — ZEP 无线电仿真与 ZEP dispatcherBenjamin Valentin (benpicco)2.2 硬件模块子系统维护者网络设备 — IEEE 802.15.4 / NRF802154 / CC2538 / KW2XRF / MRF24J40 / AT86RF2XXJosé I. Álamos (jia200x)AT86RF215Benjamin Valentin (benpicco)LoRaJosé I. Álamos (jia200x)CC110XMarian Buschsieweke (maribu)外设PeripheralsMarian Buschsieweke (maribu)2.3 内核core整个内核core由Kaspar Schleiser (kaspar030)负责。2.4 系统库子系统维护者高层定时器 APIxtimer、ztimerKaspar Schleiser (kaspar030)MTD 子系统Benjamin Valentin (benpicco)USB 支持Dylan Laduranty (dylad)Rust 支持Christian Amsüss (chrysn)、Kaspar Schleiser (kaspar030)C 支持Marian Buschsieweke (maribu)Power Management、File Systems、POSIX 支持、脚本语言、Crypto 等条目在文档中暂未列出具体维护者遇到这些领域的贡献建议通过 CODEOWNERS 中对应的路径规则定位负责人见第四节。2.5 网络子系统维护者网络栈 — GNRC / 6LowPAN / IPv6 / UDPMartine S. Lenders (miri64)IPv6 — Auto-SubnettingBenjamin Valentin (benpicco)GNRC — NetifJosé I. Álamos (jia200x)网络栈 — OpenThread / OpenWSNJosé I. Álamos (jia200x)网络栈 — LWIPMartine S. Lenders (miri64)物理/链路层 — LoRaWANJosé I. Álamos (jia200x)物理/链路层 — IEEE 802.15.4José I. Álamos (jia200x)接口 — Sock / Netif / Netdev分别由 miri64、jia200x、jia200x 负责应用协议 — CoAPnanoCoAPBenjamin Valentin (benpicco)其他 — DTLSMartine S. Lenders (miri64)2.6 构建系统、文档与测试/CI构建系统Build SystemKaspar Schleiser (kaspar030)测试/CITesting/CIKaspar Schleiser (kaspar030)文档Documentation条目暂未署名三、子系统与仓库源码目录的对应关系理解维护者分工的最佳方式是把 SUBSYSTEMS.md 中的每个子系统映射回仓库里真实的代码目录。以下映射均可在当前仓库中直接打开查证。3.1 CPU 子系统 →cpu/RIOT 的每个 CPU 架构支持都位于 cpu/ 目录下与 SUBSYSTEMS.md 的划分一一对应Atmel AVRAtmegacpu/atmega_common/、cpu/atmega328p/、cpu/atmega2560/ 等公共抽象层在cpu/atmega_commonARM7cpu/arm7_common/ 与 cpu/arm7tdmi_gba/Game Boy Advance 移植ARM Cortex-M / Atmel SAM0 线cpu/cortexm_common/ 提供 Cortex-M 公共实现cpu/sam0_common/、cpu/samd21/、cpu/samd5x/、cpu/saml21/ 对应 SUBSYSTEMS.md 中提到的 SAM D1x/D2x、L1x、L2x、D5x 系列MSP430cpu/msp430/Native含 ZEP 无线电仿真cpu/native/ZEP dispatcher 用于在 native 平台上仿真 802.15.4 网络此外还有ESP32/ESP8266cpu/esp32/、cpu/esp8266/、STM32cpu/stm32/、nRF 系列cpu/nrf52/、cpu/nrf53/、RISC-Vcpu/riscv_common/、RP2350cpu/rp2350_arm/、cpu/rp2350_riscv/等。值得注意SUBSYSTEMS.md 中 ESP32/ESP8266 条目为空但 CODEOWNERS 中明确将/cpu/esp*/与/boards/esp*/指派给 gschorcht/boards/common/esp*/同样归其负责——这正是两套机制互补的典型案例。3.2 硬件模块 →drivers/SUBSYSTEMS.md 中Hardware modules部分列出的无线电与外设驱动全部位于 drivers/ 下802.15.4 无线电drivers/at86rf2xx/jia200x 负责的主驱动、drivers/at86rf215/benpicco 单独负责CODEOWNERS 中/drivers/at86rf215/ benpicco可印证LoRa 前端drivers/sx126x/、drivers/sx127x/、drivers/sx1280/CC110Xmaribudrivers/cc110x/ 及公共层 drivers/cc1xxx_common/KW2XRF / MRF24J40drivers/kw2xrf/、drivers/mrf24j40/NRF802154作为 nRF52 板上的无线电实现在 cpu/nrf52/radio/ 下CODEOWNERS 中/cpu/nrf52/radio/nrf802154/ bergzand jia200x体现了跨子系统的联合维护外设抽象层Peripheralsmaribudrivers/periph_common/ 提供 GPIO、UART、SPI、I2C、定时器、RTC 等通用实现公共头文件位于 drivers/include/periph/SAUL 传感器注册框架drivers/saul/ 汇聚了数百种传感器驱动的适配代码。3.3 内核core→core/SUBSYSTEMS.md 中Kernel (core)由 kaspar030 负责与 CODEOWNERS 中/core/ kaspar030一致。内核源码全部位于 core/ 目录从源码文件可以直接看出 RIOT 内核的构成core/thread.c、core/thread_flags.c、core/thread_flags_group.c线程创建与线程标志机制core/sched.c调度器实现core/msg.c、core/msg_bus.c线程间消息传递core/mutex.c、core/mbox.c、core/cond.c互斥锁、邮箱、条件变量等同步原语公共 API 头文件位于 core/include/如thread.h、sched.h、msg.h、mutex.h等。3.4 系统库 →sys/SUBSYSTEMS.md 的System libraries各条目在仓库中的落点xtimer / ztimersys/xtimer/、sys/ztimer/公共头文件 sys/include/ztimer.h。CODEOWNERS 进一步细化到/sys/ztimer/ kaspar030 bergzand、/sys/xtimer/ kaspar030 MichelRottleuthner可见实际评审由多人协作完成Power Managementsys/pm_layered/分层电源管理CODEOWNERS 指派 kaspar030MTD 子系统drivers/mtd/ 为核心配套 drivers/mtd_emulated/RAM 模拟、drivers/mtd_sdcard/、drivers/mtd_sdmmc/、drivers/mtd_spi_nor/、drivers/mtd_flashpage/、drivers/mtd_mapper/File Systemssys/fs/ 与 sys/vfs/ 提供文件系统与虚拟文件系统框架具体文件系统实现则以 pkg 形式引入如 pkg/littlefs/、pkg/spiffs/、pkg/fatfs/USB 支持sys/usb/dylad 牵头CODEOWNERS 中还包含 bergzand 与 aabadie配套驱动位于 drivers/usbdev_mock/ 等POSIX 支持sys/posix/Rust 支持仓库根部的Cargo.toml/Cargo.lock等CODEOWNERS 中Cargo.* chrysn、*.rs chrysn以及 sys/rust_riotmodules/ 等模块桥接代码C 支持sys/cpp11-compat/、sys/cpp_new_delete/编码规范见仓库根部的 CODING_CONVENTIONS_C.mdCryptosys/crypto/、sys/psa_crypto/CODEOWNERS 指派 mguetschow、sys/hashes/以及 pkg 中的 pkg/mbedtls/、pkg/wolfssl/ 等第三方库。3.5 网络子系统 →sys/net/与pkg/网络是 RIOT 最庞大的子系统SUBSYSTEMS.md 的层级划分与源码目录结构高度吻合GNRC 网络栈miri64sys/net/gnrc/ 下按层组织——sys/net/gnrc/link_layer/链路层含 6LowPAN、sys/net/gnrc/network_layer/IPv6 等网络层、sys/net/gnrc/transport_layer/UDP/TCP、sys/net/gnrc/routing/rpl/RPL 路由协议Netif / Netdev / Sock 接口sys/net/netif/、sys/net/gnrc/netif/、sys/net/gnrc/sock/netdev 驱动接口头文件为 drivers/include/net/netdev.hLoRaWAN 链路层sys/net/gnrc/link_layer/lorawan/配合 LoRa 区域/MAC 协议栈 pkg/semtech-loramac/CODEOWNERS 指派 aabadie 与 jia200x应用协议nanoCoAP 位于 sys/net/application_layer/nanocoap/gcoap 位于 sys/net/application_layer/gcoap/MQTT 由 pkg/paho-mqtt/ 提供LWM2M 由 pkg/wakaama/ 提供其他网络栈LWIP 在 pkg/lwip/、OpenThread 在 pkg/openthread/、OpenWSN 在 pkg/openwsn/DTLSpkg/tinydtls/CODEOWNERS 指派 leandrolanzieri。3.6 构建系统、测试与 CI构建系统kaspar030仓库根部的 Makefile、Makefile.base 与 makefiles/ 目录其中vars.inc.mk、application.inc.mk、dependency_resolution.inc.mk等文件定义了 RIOT 基于 GNU Make 的模块化构建机制测试/CIkaspar030tests/ 目录包含数千个针对 CPU、驱动、网络栈、pkg 的测试工程CI 配置可通过 makefiles/tests/ 与仓库中的.ci文件了解fuzzing 目标位于 fuzzing/。四、双重机制SUBSYSTEMS.md 与 CODEOWNERS 如何协同SUBSYSTEMS.md 面向人——用自然语言描述职责领域而仓库根部的 CODEOWNERS 面向自动化——用 glob 路径模式为 GitHub 自动指派代码评审autoreview。两者互补且 CODEOWNERS 的规则更细粒度。CODEOWNERS 文件头部说明了其核心规则Order is important; for each modified file, thelast matching pattern takes the most precedence顺序重要对每个被修改的文件最后一个匹配的模式拥有最高优先级。举几个从 CODEOWNERS 中摘取的典型规则可以看到它们如何把 SUBSYSTEMS.md 的分工落到文件级别CODEOWNERS 规则对应 SUBSYSTEMS.md 条目/core/ kaspar030Kernel (core)/cpu/msp430*/ kaspar030 gschorchtMSP430maribu 之外还有联合维护者/cpu/atmega*/ kYc0o maribuAtmel AVRAtmega/cpu/sam0_common/ benpicco dylad keestuxAtmel SAM0 线/drivers/at86rf2xx/ jia200x miri64AT86RF2XX/drivers/cc110x/ maribuCC110X/sys/ztimer/ kaspar030 bergzandxtimer、ztimer/sys/usb/ bergzand dylad aabadieUSB 支持/sys/net/ miri64GNRC 网络栈兜底规则宽泛匹配/sys/net/gnrc/routing/rpl/ emmanuelsearchRPL细粒度规则覆盖上面的兜底规则Kconfig leandrolanzieri jia200x MrKevinWeiss任何 Kconfig 变更都会通知三位负责人从上表可以读出这套机制的两个设计要点一是兜底 细化——/sys/net/ miri64作为宽匹配兜底而/sys/net/gnrc/routing/rpl/这样的窄模式按最后匹配优先原则覆盖它确保 RPL 的变更能被专门的负责人看到二是多维护者冗余——关键路径通常列出 23 名负责人避免单点阻塞。五、维护者的工作流MAINTAINING.md 中的评审准则找到维护者只是第一步维护者拿到 Issue/PR 后如何工作则由 MAINTAINING.md 定义。该文档给出了 RIOT 维护者的完整评审基线核心分为技术准则与非技术准则两部分。技术准则按效率优先排序前一步失败则后续步骤作废审查基本问题PR 的理由是否成立、问题是否清晰、方案是否足够简单但不再更简单、PR 体量是否可控应是一个单一可解释的变更、提交历史是否干净、是否有清晰的测试说明、代码能否编译运行、是否尊重原作者版权、是否与既有 PR 重复审查代码设计检查代码重复、内存占用可对比构建体积、所有代码路径、API 一致性、错误处理一致性、变量作用域、语法/语义/逻辑错误并可借助dist/tools/coccinelle中的 Coccinelle 脚本辅助但不能替代人工审查测试 PR在native平台以及若干选定板卡上运行测试验证行为或给出清晰合理的跳过理由对照编码规范审查检查是否符合 CODING_CONVENTIONS.md可借助根目录的 uncrustify-riot.cfg 运行 Uncrustify 辅助检查审查文档确保模块级文档充分、函数级文档完整、难懂处有注释、文档无语法拼写错误。非技术准则同样重要维护者应对贡献者保持响应哪怕只是先回复会在合适时间评审、乐于提供精确有帮助的建议、尊重原作者的设计选择并始终遵循行为准则。关于维护者之间的协作MAINTAINING.md 还规定了部分评审Partial review机制——维护者可以只评审部分章节此时不应给出 approve 而应给出口头 ACK 并说明评审范围可用 Reviewed: 系列标签标记已处理/已跳过的章节全部标签齐备后才能批准合并维护者只能给自己指派 PR不能替他人指派。发布与回迁Backports流程方面每次正式发布前会宣布软冻结仅允许合并影响较小的 PR与硬冻结release 分支创建后解除 master 分支合并限制两个特性冻结期。release 分支建立后不再接受新功能回迁只接受 bug 修复或对尚未达到成熟度特性的回滚较大变更含任何 revert应在 PR 打开 48 小时后才可合并且至少需要两个 ACK安全相关的回迁可以跳过公告流程只要凑齐两个 ACK 即可合并。六、贡献者实操建议结合 SUBSYSTEMS.md、CODEOWNERS 与仓库目录结构推荐以下三步定位法确定变更所属子系统先想清楚你的改动落在 CPUcpu/、驱动drivers/、内核core/、系统库sys/、网络sys/net/、pkg/还是构建系统makefiles/再到 SUBSYSTEMS.md 对应小节查找维护者姓名条目为空时转向 CODEOWNERS若 SUBSYSTEMS.md 中该条目没有署名如 ESP32、Power Management、File Systems打开 CODEOWNERS按最后匹配优先的规则查找覆盖你改动路径的 glob 模式其中列出的维护者即评审人在 Issue/PR 中指定 assignee 并附测试说明按 SUBSYSTEMS.md 的要求指派对应模块维护者参照 MAINTAINING.md 技术准则第 1.8 条PR 描述中应包含清晰的测试指引哪些平台、哪些测试命令这会显著加快评审。最后需要提醒维护者名单与 CODEOWNERS 规则都是随项目演进的活文档本文呈现的信息以当前仓库快照为准如果你准备提交贡献请以仓库中 SUBSYSTEMS.md 与 CODEOWNERS 的最新内容为准二者共同构成了 RIOT 友好贡献文化的制度基础——每个模块都有人负责每个贡献都能找到路径。【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考