Linux 内核补丁提交清单

以下是一些开发人员如果希望他们的内核补丁提交更快被接受应该做的一些基本事情。

这些都在 Documentation/process/submitting-patches.rst 和其他关于提交 Linux 内核补丁的文档中提供的说明之上。

检查您的代码

  1. 如果您使用某个设施,请 #include 定义/声明该设施的文件。不要依赖其他头文件来引入您使用的头文件。

  2. 按照 Documentation/process/coding-style.rst 中详细说明的检查您的补丁的总体风格。

  3. 所有内存屏障 {例如, barrier()rmb()wmb()} 都需要在源代码中添加注释,解释它们正在做什么以及为什么。

检查 Kconfig 更改

  1. 任何新的或修改的 CONFIG 选项都不会搞乱配置菜单,并且默认关闭,除非它们符合 Documentation/kbuild/kconfig-language.rst 菜单属性:默认值 中记录的例外标准。

  2. 所有新的 Kconfig 选项都有帮助文本。

  3. 已根据相关的 Kconfig 组合仔细审查过。这在测试中很难做到正确---这里需要动脑筋。

提供文档

  1. 包含 kernel-doc 来记录全局内核 API。(静态函数不是必需的,但在那里也可以。)

  2. 所有新的 /proc 条目都在 Documentation/ 下记录。

  3. 所有新的内核启动参数都在 Documentation/admin-guide/kernel-parameters.rst 中记录。

  4. 所有新的模块参数都使用 MODULE_PARM_DESC() 记录。

  5. 所有新的用户空间接口都在 Documentation/ABI/ 中记录。有关更多信息,请参阅 Documentation/ABI/README。更改用户空间接口的补丁应抄送至 linux-api@vger.kernel.org

  6. 如果补丁添加了任何 ioctl,那么还需要更新 Documentation/userspace-api/ioctl/ioctl-number.rst

使用工具检查您的代码

  1. 在提交之前使用补丁样式检查器(scripts/checkpatch.pl)检查是否有明显的违规行为。您应该能够证明补丁中仍然存在的任何违规行为是合理的。

  2. 使用 sparse 清洁地检查。

  3. 使用 make checkstack 并修复它发现的任何问题。请注意, checkstack 不会明确指出问题,但任何在堆栈上使用超过 512 字节的函数都可能是更改的候选对象。

构建您的代码

  1. 干净地构建

  1. 使用适用或修改的 CONFIG 选项 =y=m=n。没有 gcc 警告/错误,没有链接器警告/错误。

  2. 通过 allnoconfigallmodconfig

  3. 在使用 O=builddir 时成功构建

  4. 任何 Documentation/ 更改都成功构建,没有新的警告/错误。使用 make htmldocsmake pdfdocs 检查构建并修复任何问题。

  1. 通过使用本地交叉编译工具或其他构建场在多个 CPU 架构上构建。请注意,ppc64 是一个很好的交叉编译检查架构,因为它倾向于将 unsigned long 用于 64 位数量。

  2. 新添加的代码已使用 gcc -W 编译(使用 make KCFLAGS=-W)。这将生成大量噪声,但对于查找诸如“警告:有符号和无符号之间的比较”之类的错误很有用。

  3. 如果您修改的源代码依赖于或使用与以下 Kconfig 符号相关的任何内核 API 或功能,那么请使用相关的 Kconfig 符号禁用和/或 =m (如果该选项可用)测试多个构建 [不是所有这些都同时进行,只是它们的各种/随机组合]

    CONFIG_SMPCONFIG_SYSFSCONFIG_PROC_FSCONFIG_INPUTCONFIG_PCICONFIG_BLOCKCONFIG_PMCONFIG_MAGIC_SYSRQCONFIG_NETCONFIG_INET=n (但后者使用 CONFIG_NET=y)。

测试您的代码

  1. 已在同时启用 CONFIG_PREEMPTCONFIG_DEBUG_PREEMPTCONFIG_SLUB_DEBUGCONFIG_DEBUG_PAGEALLOCCONFIG_DEBUG_MUTEXESCONFIG_DEBUG_SPINLOCKCONFIG_DEBUG_ATOMIC_SLEEPCONFIG_PROVE_RCUCONFIG_DEBUG_OBJECTS_RCU_HEAD 的情况下进行了测试。

  2. 已在有和没有 CONFIG_SMPCONFIG_PREEMPT 的情况下进行了构建和运行时测试。

  3. 所有代码路径都已在启用所有 lockdep 功能的情况下进行了练习。

  4. 已检查注入至少 slab 和页面分配失败的情况。请参阅 Documentation/fault-injection/。如果新代码很重要,则添加特定于子系统的故障注入可能是合适的。

  5. 已使用 linux-next 的最新标签进行测试,以确保它仍然可以使用所有其他排队的补丁以及 VM、VFS 和其他子系统中的各种更改。