2年前指导公司内部人员如何提交Linux内核Patch时整理的wiki资料。在这里共享，主要介绍Patch作成时，以及社区对应时的注意点。
1. patch制作
1.1 bug修正
bug修正时请注意以下几点：
- 是否没有多余的注释。
- 注释是否符合kernel doc format。
- 是否include了多余的头文件。
- 函数原型是否用了#ifdef。
- 一个画面内不能显示#ifdef和#endif时，是否添加了/* CONFIG_NAME */ 这 样的注释。
- 应该使用EXPORT_SYMBOL_GPL()的地方是否使用了EXPORT_SYMBOL()。
- 使用scripts/checkpatch.pl检查一下。
- 修正后是否再次编译并测试。
- 修正后编译是否有warning。
1.2 生成patch
生成patch时请注意以下几点：
- patch是否太大超过邮件服务器接收单封邮件的上限。
- 一个patch只修正一个问题。类似patch分为多个作成系列，用[n/m]的形式发送。
- 是否明确描述了patch的目的。patch被采用时，这些说明会直接放入Changelog。尤其是反映了社区的意见后再次投稿时容易忘记，请注意。
- 是否对正确的版本制作的patch。
- patch制作时的当前路径是否是新旧两个版本所在路径的父目录。
- patch制作后是否应用并再次测试过。
- 内核patch最好使用git生成。
- diff的参数尽量使用 -Nurp
2. patch推进
如果推进时已经有人正在社区中推进相关内容的话，请停止patch的提交，而只参与讨论。
2.1 问题再现方式
- 请假设将要面对的社区的维护人员不能理解你在source层的解释，他只能理解更浅显的说明方式。
- 再现的程序尽量是一组command的组合。
- 如果有多种情况可以再现同一个bug的话，那请挑选最自然的方式。假设有个bug导致任何l打头的命令都不能使用。再现方法有多种，以下三种，哪个更好？
a.#lamnotacmd
b.#lshal
c.#ls
首先abc确实都能再现bug，但是a使用了一个不存在的命令，b使用了一个存在的命令，但是并不常用，显然c在实际应用中更加频繁和自然。c作为再现方式的话更容易被社区的维护人员理解和接受。
- 如果这个bug有时会引起kernel panic，有时不会，那请不要忘了告诉社区kernel panic的事，这样可以引起重视。
2.2 邮件格式
- 邮件的标题是否合适。
- 投稿多个不同的patch时，必须分别采用不同的邮件标题。(标题为 patch名。例:”Subject:[PATCH] mm: fix a bug in container driver” → fix-a-bug-in-container-driver.patch)
- 投稿一个系列的patch(为了一个目的制作的patch，因为太大的原因 而进行了分割)时，标题上必须添加编号。例：”Subject:[PATCH 1/4]…”
- 邮件采用纯文本格式，并且每行字长小于72字节，不要使用英语以外的文字。
- 邮件的签名不要使用公司统一的复杂签名。
- 邮件作成后，直接另存为*.patch，用这个patch再试验一次是否能打上。因为社区维护人员大都直接把mail另存后作为patch使用。
- 是否添加了必要的Signed-off-by， Reviewed-by， Tested-by。
- Thunder Bird 发送patch时的配置(防止tab自动转换为空格):
- 1 工具->邮件/新闻账户设置 选择“通讯录”去掉“以HTML格式编写消息”的选框
- 2 在C:\Documents and Settings\YourName\Application Data\Thunderbird\Profiles\xxxxxx.default目录下生成user.js文件，文件内容如下
- user_pref(”mailnews.wraplength”, 0);
- user_pref(”mailnews.send_plaintext_flowed”, false);
- 3 重启ThunderBird就可以了
2.3 和社区讨论
向社区投稿时请注意以下几点：
- 投稿地址是否正确。(查看MAINTAINERS中相关人员后To or CC)
- 讨论时回复邮件请不要置顶回复，应该在对方的邮件的正文中插入回复。
2.4 patch采用后的对应
patch经过社区review后，认为没有问题，就会被采用。 但是采用后，发生问题的可能性仍然存在。 比如，某个服务器制造商在自己的服务器上运用patch后，可能会由于硬件平台的差异，引起新的障害，这个时候大家就会讨论是否要把patch退回。 因此，出现这种问题后，需要迅速对应，否则很有可能被采用的patch又被退回。
Tags: community, git, Kernel, Linux, OpenSource, Patch, process