RIOT 内存不足自动检测工具 insufficient_memory自动维护 Makefile.ci 板卡列表的 CI 利器【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOTRIOT 是面向物联网的嵌入式实时操作系统其仓库中同时维护着数百个板卡board与成百上千的测试/示例应用。由于不同板卡的 FlashROM与 RAM 容量差异悬殊同一份测试代码在部分资源紧张的板卡上根本无法完成链接。为了在 CI 中准确记录哪些板卡跑不了哪个应用RIOT 提供了dist/tools/insufficient_memory工具集它通过真实构建所有测试与示例自动判定板卡内存是否足够并把结果写入各应用目录下的Makefile.ci文件。阅读完本文你将掌握该工具的完整用法、底层判定机制以及如何在新增板卡时一键批量更新整个仓库的内存白名单。一、工具解决的问题CI 构建与内存受限板卡RIOT 的 CI 会针对大量板卡逐一编译测试与示例。如果一个板卡的 Flash 太小某些测试在链接阶段就会报出类似region FLASH overflowed by ... bytes的错误——这类失败并非代码缺陷而是硬件资源限制理应被 CI 记录并跳过。为此RIOT 约定在每个测试/示例应用的目录下维护一个Makefile.ci文件其中通过变量BOARD_INSUFFICIENT_MEMORY列出所有因内存不足而无法运行该应用的板卡。例如 tests/bench/msg_pingpong/Makefile.ci 内容为BOARD_INSUFFICIENT_MEMORY : \ atmega8 \ nucleo-l011k4 \ stm32f030f4-demo \ #注意末尾以\续行、以#收尾的写法这是 RIOT Makefile.ci 的统一格式由工具自动生成。若某个应用在任意板卡上都能编译其 Makefile.ci 也会存在只是列表为空如 tests/bench/sizeof_coretypes/Makefile.ciBOARD_INSUFFICIENT_MEMORY : \ #然而为数百个应用手工维护这份板卡黑名单几乎不可能于是 RIOT 提供了自动化脚本完成该工作。二、工具集组成三个文件各司其职dist/tools/insufficient_memory 目录下共包含三个文件覆盖增量更新与全量重建两条路径文件作用update_insufficient_memory_board.sh给定一个板卡遍历仓库中所有测试与示例逐一构建内存不足则把该板卡自动加入对应的Makefile.ci增量更新主脚本create_makefile.ci.sh站在某个应用目录下遍历所有支持的板卡重新构建从零生成该应用的Makefile.ciMakefile.for_sh被上述两个脚本复用的 Makefile 片段负责以统一格式写出/改写Makefile.ci文件三、update_insufficient_memory_board.sh为指定板卡增量更新黑名单这是 README 介绍的核心脚本用法与 README 一致update_insufficient_memory_board.sh board_name其语义是以某个板卡为维度扫描仓库里每一个测试与示例凡是该板卡内存放不下的就把该板卡写入对应应用的Makefile.ci。3.1 获取待测应用清单脚本先通过 RIOT 的构建系统列出全部应用update_insufficient_memory_board.sh#L52APPLICATIONS${APPLICATIONS} $(make -sC ${RIOTBASE} info-applications)info-applications是 RIOT 顶层 Makefile 提供的元信息目标返回仓库中所有可构建应用的路径列表。随后脚本对每个应用循环执行构建判定。3.2 先移除、再判定、最后回写针对每个应用脚本执行三步核心操作update_insufficient_memory_board.sh#L57-L70从 Makefile.ci 中临时移除该板卡调用Makefile.for_sh的REMOVE_BOARDS变量把板卡先从BOARD_INSUFFICIENT_MEMORY中剔除。脚本注释明确解释了原因CI 构建模式RIOT_CI_BUILD1下如果板卡已在列表中链接步骤会被直接跳过输出skipping link step这样就无法真正测出该板卡当前到底能不能链接通过。以该板卡真实构建应用执行make BOARD${BOARD} -C ${RIOTBASE}/${application}并把完整输出写入临时文件供后续判定。按构建结果分类处理构建失败时用grep匹配链接器输出特征识别失败原因匹配overflowed、not within region、wraps around address space、overlaps section等关键词判定为内存不足too big随即通过ADD_BOARDS把该板卡写回Makefile.ci匹配not whitelisted、unsatisfied feature requirements、Some feature requirements are blacklisted:等关键词判定为板卡不支持not supported不修改列表其他错误一律视为构建失败build failed打印完整日志供人工排查。3.3 输出与并行构建脚本针对每个应用输出一行彩色状态终端不支持 8 色时自动降级为无色见 update_insufficient_memory_board.sh#L19-L35绿色OK构建成功且正常完成链接蓝色too big内存不足已自动加入 Makefile.ci黄色not supported板卡不支持该应用的功能需求无需记录青色skipped链接步骤被跳过skipping link step红色build failed非内存原因的构建错误并输出日志。同时脚本检测nproc可用时自动追加-j$(nproc)并行构建参数以加速全量扫描update_insufficient_memory_board.sh#L10-L12。3.4 Docker 构建选项 --no-docker默认情况下脚本会导出BUILD_IN_DOCKER1与DOCKER_MAKE_ARGS将构建放入 RIOT 标准的 Docker 容器中以获得一致的交叉编译环境如果本机工具链完备、希望直接本地构建可传入--no-dockerupdate_insufficient_memory_board.sh --no-docker board_name传入该选项后MAKE_ARGS会被作为本地参数直接传递给makeupdate_insufficient_memory_board.sh#L37-L44。3.5 参数校验脚本对参数做了基本校验未传入板卡名时打印usage: $0 board并退出码 1update_insufficient_memory_board.sh#L14-L17。RIOTBASE由脚本自身相对于仓库根目录推算$(dirname $0)/../../..因此在仓库任意位置、以绝对路径或相对路径调用均可。四、create_makefile.ci.sh从零重建单个应用的板卡列表当应用本身的代码大幅变动或仓库新增了大量板卡后更彻底的做法是丢弃旧列表、重新全量生成。create_makefile.ci.sh正是为此设计它面向单个应用遍历该应用支持的所有板卡构建一次收集全部内存不足的板卡最终生成一份全新的 Makefile.ci。该脚本需在应用目录内执行它用APP_DIR$(pwd)记录当前目录create_makefile.ci.sh#L13。其流程为删除并重建空的Makefile.cicreate_makefile.ci.sh#L46-L47通过make info-boards-supported获取该应用支持的板卡全集create_makefile.ci.sh#L50对每个板卡执行make clean all同样按关键词分类构建结果相比增量脚本它在内存不足判定中额外多匹配了一个关键词does not fit in ROMcreate_makefile.ci.sh#L60并在循环结束后一次性把收集到的所有板卡通过ADD_BOARDS写入全新的Makefile.cicreate_makefile.ci.sh#L84-L85。该脚本还被 RIOT 构建系统包装为顶层 Makefile 目标。在 makefiles/info-global.inc.mk#L149-L150 中可以看到generate-Makefile.ci: $(RIOTTOOLS)/insufficient_memory/create_makefile.ci.sh也就是说在任意应用目录下执行make generate-Makefile.ci即可触发同一套全量重建流程把脚本接入常规 Make 工作流。五、Makefile.for_sh统一的黑名单书写格式两个脚本都依赖 Makefile.for_sh 来实际写入Makefile.ci。它的核心逻辑Makefile.for_sh#L1-L18是通过-include $(DIR)/Makefile.ci读入应用现有的板卡列表追加ADD_BOARDS中的新板卡并用filter-out剔除REMOVE_BOARDS中的板卡若结果为空则输出skipping empty Makefile.ci避免生成空洞文件否则用create_Makefile.ci函数按 RIOT 惯例写出BOARD_INSUFFICIENT_MEMORY : \的多行续行格式板卡名经sort排序以保证列表稳定、利于 diff 审查。由于该 Makefile 通过DIR变量定位应用目录同一份模板既能服务增量更新单个板卡也能服务全量重建单应用这正是工具集把格式逻辑单独抽取出来的原因。六、与 CI 构建系统的衔接RIOT_CI_BUILD 与链接跳过理解该工具的关键在于 RIOT 的 CI 构建约定脚本会设置export RIOT_CI_BUILD1update_insufficient_memory_board.sh#L46、create_makefile.ci.sh#L42。在此模式下如果某个板卡已经出现在应用的BOARD_INSUFFICIENT_MEMORY中构建系统会跳过链接步骤并输出skipping link step——这正是两个脚本需要先移除板卡再构建的原因只有让链接真正执行才能判定该板卡当前的内存状态是否已经改变例如代码优化后原本放不下的应用现在放得下了。同时构建系统本身也会使用这份列表CI 在按板卡批量编译时凡是命中BOARD_INSUFFICIENT_MEMORY的应用会得到快速跳过既避免了无意义的失败又大幅压缩了 CI 的编译总量。因此Makefile.ci并非普通的工程文档而是直接参与 RIOT CI 判定流程的构建配置。七、实战场景与使用建议综合上述机制这套工具最典型的应用场景如下场景一为仓库新增一块板卡。板卡的Makefile.ci尚未记录任何内存约束此时运行dist/tools/insufficient_memory/update_insufficient_memory_board.sh new_board_name脚本会遍历全部测试与示例凡链接不下的应用都会自动把新板卡加入其Makefile.ci。执行后建议用git diff检查改动确认每一条新增记录都对应真实的overflowed/not within region等内存错误。场景二应用代码大幅改动后重建黑名单。在应用目录下直接运行make generate-Makefile.ci等价于执行 create_makefile.ci.sh以当前代码为准重新核定哪些板卡内存不足。场景三本地工具链完整、无需容器。两个脚本均支持--no-docker选项可绕过 Docker 直接使用本机交叉编译环境update_insufficient_memory_board.sh --no-docker board_name八、小结dist/tools/insufficient_memory是 RIOT 构建体系中一套小而精的自动化工具update_insufficient_memory_board.sh以板卡为维度增量维护所有应用的Makefile.cicreate_makefile.ci.sh以应用为维度全量重建列表Makefile.for_sh则统一了黑名单的书写格式。三个脚本通过真实的链接过程、对链接器报错关键词的模式匹配以及RIOT_CI_BUILD模式的联动让哪些板卡内存不足这一结论始终来自真实构建而非人工估计——这正是 RIOT 在数百块板卡、上千个应用间维持 CI 稳定的重要保障。【免费下载链接】RIOTRIOT - The friendly OS for IoT项目地址: https://gitcode.com/GitHub_Trending/riot/RIOT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考