尧图网站建设 
如何为btrfs-progs贡献代码内核风格开发流程与CI测试完全指南【免费下载链接】btrfs-progsDevelopment of userspace BTRFS tools项目地址: https://gitcode.com/gh_mirrors/bt/btrfs-progsbtrfs-progs 是 Linux 下管理 btrfs 文件系统的用户态工具集包含btrfs主管理工具、mkfs.btrfs格式化工具及btrfs-image等实用程序。本文带你完整走通为 btrfs-progs 贡献代码的内核风格开发流程从提交规范的补丁、写好 changelog到通过 GitHub 拉取请求PR触发 CI 构建与全套功能测试新手也能照着做出第一个被合并的贡献。项目结构与代码布局动手前先用 5 分钟认识仓库布局这决定了你的补丁该改哪里cmds/—— 各子命令实现如 balance.c、scrub.c、send.ccheck/——btrfs check修复引擎见 check/main.ckernel-shared/—— 与内核共享的核心逻辑ctree、extent-tree、volumes 等tests/—— 完整测试套件详见 tests/README.mdci/—— 容器化 CI 环境详见 ci/README.mdDocumentation/—— 所有手册页与文档RST Sphinx 构建理解 btrfs 内部结构时Documentation/dev/Developer-s-FAQ.rst 是官方给新贡献者的入门问答强烈建议精读。第一步搭建开发环境与构建按照 INSTALL 文件安装依赖libuuid、libblkid、liblzo2、zlib、libzstd 等然后从 git 源码构建git clone https://gitcode.com/gh_mirrors/bt/btrfs-progs cd btrfs-progs ./autogen.sh ./configure make构建系统基于 autotoolsINSTALL 还说明了静态二进制、busybox 风格的btrfs.box一体化构建方式。首次贡献建议顺手验证make test能跑通这代表你的本地环境已具备提交前自检能力。内核风格开发规范补丁三要素btrfs-progs 的开发模式与 Linux 内核高度一致见 README.md 的 Development 章节核心只有三条硬规矩1. 一个补丁只做一个逻辑变更不要混着提交 bug 修复、清理和新功能。不确定怎么切分时评审阶段维护者会指出——所以宁可多拆。2. 规范的主题行用户态补丁以btrfs-progs:开头再加子系统前缀和简短描述。官方 FAQ 中的示例Documentation/dev/Developer-s-FAQ.rstSubject: [PATCH] btrfs-progs: enhance documentation of balance Add examples of typical balance use, common problems and how to resolve them. Signed-off-by: Jane Doe janedoe.org --- Documentation/btrfs-balance.txt | 20 -3. 说清 why、how、what 的 changelog最常见的打回原因不是代码写得差而是 changelog 没解释为什么改、怎么坏的、用户可见的影响是什么。多花 5 分钟写清动机比多花 5 小时改代码更有效。Signed-off-by 签名非重大改动错字、文档不是强制的但建议保留——它记录作者身份。不熟悉签名流程也没关系维护者说明贡献不会因此被拒可以用 issue 或 PR 链接代替署名。补丁提交方式邮件列表 vs 拉取请求项目同时支持两种渠道README.md邮件列表linux-btrfsvger.kernel.org所有补丁的默认渠道配合git format-patch与git send-email。修订版补丁需在---分隔线下保留历版 changelog如V2: fixed typo。GitHub 拉取请求更适合代码或文档贡献PR 会自动触发 CI 构建检查。PR 的工作流细节写在 Documentation/dev/GithubReviewWorkflow.rst对devel分支开 PR也可对master但可能错过其他开发中的变更需要更新时向同一分支推送即可合并策略是rebase and merge变更会被应用到devel当前头上评审者会逐行留评论你可以解释设计或修改代码后标记Resolved若确定改动不需要 CI 验证如纯文档在 changelog 里加[skip ci] 小建议文档类贡献合并概率最高、速度最快。如果你是第一次接触 btrfs从修正手册页措辞、补充 Documentation/ 下的示例开始是最友好的入门路径。CI 测试完全指南你的 PR 会被怎么检验PR 自动触发哪些测试拉取请求工作流定义在 .github/workflows/pull-request.yml在 ubuntu-24.04 上依次执行动态构建make静态构建make static、btrfs.box.static六类功能测试test-cli、test-mkfs、test-check、test-check-lowmem、test-misc、test-fuzz失败时自动上传tests/*-results.txt日志供排查也就是说提交 PR 前先在本地把对应测试跑绿能大幅缩短返工周期。本地运行测试套件测试原则输出全部落日志、首个失败即停保留现场便于调试、自动探测系统能力并跳过不支持的项tests/README.md。# 从顶层目录运行 make test # 全部 make test-fsck make test-convert # 用 TEST 掩码精确定位单个测试 make TEST012* test-misc测试目录分工目录用途tests/fsck-tests/可被 fsck 修复的损坏镜像tests/convert-tests/ext2/3/4、reiserfs 转换覆盖tests/fuzz-tests/模糊/特制镜像工具不应崩溃tests/cli-tests/命令行选项组合验证tests/misc-tests/以上皆非的其他场景通用 shell 辅助函数集中在 tests/common模板脚本在 tests/template/。为新功能写测试官方 7 步流程tests/README.md 给出了标准写法最简测试骨架只需十几行#!/bin/bash # Simple test to create a new filesystem and test that it can be mounted source $TEST_TOP/common setup_root_helper prepare_test_dev run_check_mkfs_test_dev run_check_mount_test_dev run_check_umount_test_dev关键约定目录命名用三位序号-短横线描述取当前最大未用序号test.sh必须可执行开头注释说明测试的 bug 与验证方式修复补丁必须排在验证测试之前提交保证 git 历史可 bisect提交信息引用引入/修复 bug 的 commit标题可带新测试目录名容器化 CI在目标发行版上验证兼容性btrfs-progs 强调向后兼容ci/ 目录提供了一组发行版容器镜像AlmaLinux 10、CentOS 8、Rocky 9、openSUSE Leap 15.3/16.0/Tumbleweed、musli386/x86_64每个目录含Dockerfile、docker-run、run-tests如 ci/images/ci-musl-x86_64/。# 准备镜像 cd ci/images/ci-openSUSE-tumbleweed-x86_64 ./docker-build # 构建 跑测试可启用 ASan 等 sanitizer ./docker-run --envDasan -- bash -c ./test-build devel --disable-documentation \ ./run-tests /tmp/btrfs-progs-devel容器必须特权运行要创建 loop 设备、挂载文件系统。CI 基础设施的最低要求内核 ≥ 5.15、可 losetup、可 mount也记录在 ci/README.md。常见问题速答我的补丁被静默忽略怎么办先确认是否发到正确渠道、changelog 是否说明了动机等待一段时间后发一条温和的 pingDocumentation/dev/Developer-s-FAQ.rst 的 Repeated submissions 章节。能用 PR 直接提一大坨代码吗默认补丁应走邮件列表评审PR 更适合小改动或文档。想走 pull 分支模式需要无风格违规、高质量实现、好的 changelog且分支基点明确通常是稳定发布点或不再 rebase 的开发点。新文件要加 GPL 版权头吗不需要。项目采用 SPDX 标准贡献历史由 git 的 Signed-off-by 链记录社区明确不鼓励在新文件里添加版权声明。什么是 [RFC] 补丁标题里带[RFC]request for comments表示求评论的早期版本用来在写完整实现前确认方向可能帮你省下数小时编码。提交清单发出前的最后检查一个补丁只做一件事主题行符合btrfs-progs:前缀规范changelog 讲清了 why / how / what本地make构建通过相关make test-*全绿修复补丁先于验证测试提交文档变更与代码变更合理拆分可同补丁也可独立PR 目标分支为devel或邮件已发至 linux-btrfs 列表跟着这份清单走你的贡献就具备了内核风格社区认可的全部要件。祝你的第一个补丁顺利合入 【免费下载链接】btrfs-progsDevelopment of userspace BTRFS tools项目地址: https://gitcode.com/gh_mirrors/bt/btrfs-progs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何为btrfs-progs贡献代码：内核风格开发流程与CI测试完全指南
如何为btrfs-progs贡献代码内核风格开发流程与CI测试完全指南【免费下载链接】btrfs-progsDevelopment of userspace BTRFS tools项目地址: https://gitcode.com/gh_mirrors/bt/btrfs-progsbtrfs-progs 是 Linux 下管理 btrfs 文件系统的用户态工具集包含btrfs主管理工具、mkfs.btrfs格式化工具及btrfs-image等实用程序。本文带你完整走通为 btrfs-progs 贡献代码的内核风格开发流程从提交规范的补丁、写好 changelog到通过 GitHub 拉取请求PR触发 CI 构建与全套功能测试新手也能照着做出第一个被合并的贡献。项目结构与代码布局动手前先用 5 分钟认识仓库布局这决定了你的补丁该改哪里cmds/—— 各子命令实现如 balance.c、scrub.c、send.ccheck/——btrfs check修复引擎见 check/main.ckernel-shared/—— 与内核共享的核心逻辑ctree、extent-tree、volumes 等tests/—— 完整测试套件详见 tests/README.mdci/—— 容器化 CI 环境详见 ci/README.mdDocumentation/—— 所有手册页与文档RST Sphinx 构建理解 btrfs 内部结构时Documentation/dev/Developer-s-FAQ.rst 是官方给新贡献者的入门问答强烈建议精读。第一步搭建开发环境与构建按照 INSTALL 文件安装依赖libuuid、libblkid、liblzo2、zlib、libzstd 等然后从 git 源码构建git clone https://gitcode.com/gh_mirrors/bt/btrfs-progs cd btrfs-progs ./autogen.sh ./configure make构建系统基于 autotoolsINSTALL 还说明了静态二进制、busybox 风格的btrfs.box一体化构建方式。首次贡献建议顺手验证make test能跑通这代表你的本地环境已具备提交前自检能力。内核风格开发规范补丁三要素btrfs-progs 的开发模式与 Linux 内核高度一致见 README.md 的 Development 章节核心只有三条硬规矩1. 一个补丁只做一个逻辑变更不要混着提交 bug 修复、清理和新功能。不确定怎么切分时评审阶段维护者会指出——所以宁可多拆。2. 规范的主题行用户态补丁以btrfs-progs:开头再加子系统前缀和简短描述。官方 FAQ 中的示例Documentation/dev/Developer-s-FAQ.rstSubject: [PATCH] btrfs-progs: enhance documentation of balance Add examples of typical balance use, common problems and how to resolve them. Signed-off-by: Jane Doe janedoe.org --- Documentation/btrfs-balance.txt | 20 -3. 说清 why、how、what 的 changelog最常见的打回原因不是代码写得差而是 changelog 没解释为什么改、怎么坏的、用户可见的影响是什么。多花 5 分钟写清动机比多花 5 小时改代码更有效。Signed-off-by 签名非重大改动错字、文档不是强制的但建议保留——它记录作者身份。不熟悉签名流程也没关系维护者说明贡献不会因此被拒可以用 issue 或 PR 链接代替署名。补丁提交方式邮件列表 vs 拉取请求项目同时支持两种渠道README.md邮件列表linux-btrfsvger.kernel.org所有补丁的默认渠道配合git format-patch与git send-email。修订版补丁需在---分隔线下保留历版 changelog如V2: fixed typo。GitHub 拉取请求更适合代码或文档贡献PR 会自动触发 CI 构建检查。PR 的工作流细节写在 Documentation/dev/GithubReviewWorkflow.rst对devel分支开 PR也可对master但可能错过其他开发中的变更需要更新时向同一分支推送即可合并策略是rebase and merge变更会被应用到devel当前头上评审者会逐行留评论你可以解释设计或修改代码后标记Resolved若确定改动不需要 CI 验证如纯文档在 changelog 里加[skip ci] 小建议文档类贡献合并概率最高、速度最快。如果你是第一次接触 btrfs从修正手册页措辞、补充 Documentation/ 下的示例开始是最友好的入门路径。CI 测试完全指南你的 PR 会被怎么检验PR 自动触发哪些测试拉取请求工作流定义在 .github/workflows/pull-request.yml在 ubuntu-24.04 上依次执行动态构建make静态构建make static、btrfs.box.static六类功能测试test-cli、test-mkfs、test-check、test-check-lowmem、test-misc、test-fuzz失败时自动上传tests/*-results.txt日志供排查也就是说提交 PR 前先在本地把对应测试跑绿能大幅缩短返工周期。本地运行测试套件测试原则输出全部落日志、首个失败即停保留现场便于调试、自动探测系统能力并跳过不支持的项tests/README.md。# 从顶层目录运行 make test # 全部 make test-fsck make test-convert # 用 TEST 掩码精确定位单个测试 make TEST012* test-misc测试目录分工目录用途tests/fsck-tests/可被 fsck 修复的损坏镜像tests/convert-tests/ext2/3/4、reiserfs 转换覆盖tests/fuzz-tests/模糊/特制镜像工具不应崩溃tests/cli-tests/命令行选项组合验证tests/misc-tests/以上皆非的其他场景通用 shell 辅助函数集中在 tests/common模板脚本在 tests/template/。为新功能写测试官方 7 步流程tests/README.md 给出了标准写法最简测试骨架只需十几行#!/bin/bash # Simple test to create a new filesystem and test that it can be mounted source $TEST_TOP/common setup_root_helper prepare_test_dev run_check_mkfs_test_dev run_check_mount_test_dev run_check_umount_test_dev关键约定目录命名用三位序号-短横线描述取当前最大未用序号test.sh必须可执行开头注释说明测试的 bug 与验证方式修复补丁必须排在验证测试之前提交保证 git 历史可 bisect提交信息引用引入/修复 bug 的 commit标题可带新测试目录名容器化 CI在目标发行版上验证兼容性btrfs-progs 强调向后兼容ci/ 目录提供了一组发行版容器镜像AlmaLinux 10、CentOS 8、Rocky 9、openSUSE Leap 15.3/16.0/Tumbleweed、musli386/x86_64每个目录含Dockerfile、docker-run、run-tests如 ci/images/ci-musl-x86_64/。# 准备镜像 cd ci/images/ci-openSUSE-tumbleweed-x86_64 ./docker-build # 构建 跑测试可启用 ASan 等 sanitizer ./docker-run --envDasan -- bash -c ./test-build devel --disable-documentation \ ./run-tests /tmp/btrfs-progs-devel容器必须特权运行要创建 loop 设备、挂载文件系统。CI 基础设施的最低要求内核 ≥ 5.15、可 losetup、可 mount也记录在 ci/README.md。常见问题速答我的补丁被静默忽略怎么办先确认是否发到正确渠道、changelog 是否说明了动机等待一段时间后发一条温和的 pingDocumentation/dev/Developer-s-FAQ.rst 的 Repeated submissions 章节。能用 PR 直接提一大坨代码吗默认补丁应走邮件列表评审PR 更适合小改动或文档。想走 pull 分支模式需要无风格违规、高质量实现、好的 changelog且分支基点明确通常是稳定发布点或不再 rebase 的开发点。新文件要加 GPL 版权头吗不需要。项目采用 SPDX 标准贡献历史由 git 的 Signed-off-by 链记录社区明确不鼓励在新文件里添加版权声明。什么是 [RFC] 补丁标题里带[RFC]request for comments表示求评论的早期版本用来在写完整实现前确认方向可能帮你省下数小时编码。提交清单发出前的最后检查一个补丁只做一件事主题行符合btrfs-progs:前缀规范changelog 讲清了 why / how / what本地make构建通过相关make test-*全绿修复补丁先于验证测试提交文档变更与代码变更合理拆分可同补丁也可独立PR 目标分支为devel或邮件已发至 linux-btrfs 列表跟着这份清单走你的贡献就具备了内核风格社区认可的全部要件。祝你的第一个补丁顺利合入 【免费下载链接】btrfs-progsDevelopment of userspace BTRFS tools项目地址: https://gitcode.com/gh_mirrors/bt/btrfs-progs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考