簡介
向Linux社區提交補丁並不頻繁，某一次提交后可能了然於胸，過段時間總會忘記，於是就有了這篇文章
這篇文章是我真實提交的步驟，沒有嚴格按官方的要求和建議來，但能覆蓋大多數問題
如果希望詳細學習如何提交，參考《如何讓你的改動進入內核》
下載代碼
在官網下載最新代碼，或者通過MAINTAINERS尋找對應子系統的倉庫代碼。
以我要提交pstore的子系統為例，在MAINTAINERS中找到以下信息：
PSTORE FILESYSTEM
M: Kees Cook <keescook@chromium.org>
M: Anton Vorontsov <anton@enomsg.org>
M: Colin Cross <ccross@android.com>
M: Tony Luck <tony.luck@intel.com>
S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git for-next/pstore
F: fs/pstore/
F: include/linux/pstore*
F: drivers/firmware/efi/efi-pstore.c
F: drivers/acpi/apei/erst.c
F: Documentation/admin-guide/ramoops.rst
F: Documentation/admin-guide/pstore-block.rst
F: Documentation/devicetree/bindings/reserved-memory/ramoops.txt
K: \b(pstore|ramoops|blkoops)
既然子系統有獨立倉庫分支，那就下載這個分支的代碼，並切換到對應分支
git clone git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git pstore-tree
git checkout for-next/pstore
創建補丁
在下載的最新代碼倉庫中，本地提交自己的補丁后，就可以把補丁提取出文件來。
如果是單個補丁，用下面的命令：
git format-patch --subject-prefix='PATCH' -i HEAD~
如果是系列補丁，用下面的命令：
git format-patch --cover-letter --subject-prefix='PATCH' -N #這里的N是你要提取的補丁個數
上面兩個命令比較通用了，其中
subject-prefix 是為郵件標題添加個前綴
cover-letter 是為系列郵件創建封面郵件
郵件前綴
一個郵件可有多個郵件前綴。有以下常見的郵件前綴，我的理解不確定是否准確，僅供參考
| 前綴 | 含義 |
|---|---|
| PATCH | 常規的且正式的補丁 |
| RFC | 不是要正式提上去的，希望一起討論這個補丁，用來說明方向，看看意見 |
| RESEND | 郵件發過了但好幾周都沒人鳥，可能被遺忘了，重新發 |
如果根據maintainer的意見，修改后重新提交，則需要在前綴后面加上版本。
例如第5個版本：
git format-patch --subject-prefix='PATCH v5' -i HEAD~
提取出來的補丁，效果大概是這樣：
[...]
Subject: [PATCH v5] ....
[...]
郵件封面
當有多個補丁來做某一件事情，我們需要提交系列補丁，那么最好有個郵件封面，介紹這系列補丁
那么，就會多出個0000編號的補丁：
0000-cover-letter.patch
0001-...
0002-...
在封面補丁里，就會列出了系列補丁包含哪些補丁？改了啥文件？如下：
[...]
Subject: [PATCH v5] *** SUBJECT HERE ***
*** BLURB HERE ***
WeiXiong Liao (1):
mtd: ...
drivers/mtd/Kconfig | 8 +
drivers/mtd/Makefile | 1 +
[...]
3 files changed, 540 insertions(+)
其中，封面補丁里面郵件頭和正文需要自己寫，可別冒失就這么發出去了
SUBJECT HERE ： 封面郵件頭，一句話總結系列郵件
BLURB HERE ： 封面郵件正文，講講系列郵件是為了做什么
編譯檢查
編譯進內核和編譯成模塊，都要試試，確保都能編譯過
風格檢查
Linux內核有提供腳本進行補丁的風格檢查，執行下面命令：
$ ./scripts/checkpatch.pl 00*.patch
腳本爆出錯誤啦，改！在本地倉庫改，然后提交到本地倉庫，重新提出補丁，再次檢查。只至沒有報錯為止。
錯誤都改！如果是警告，建議改，除非你覺得修改是合理的，可以忽略
還有一些是誤報/建議，自己酌情看看是否要修，例如：
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#71:
new file mode 100644
上面警告信息顯示添加了新文件，需要我們確認新文件是否有在MAINTAINERS的記錄中。實際上是有的，因為MAINTAINERS中文件是模糊匹配的，剛好囊括了我新添加的文件，因此可以忽略這警告。
kernel-doc注釋規范檢查
Linux系統上的kernel-doc機制，可以在源碼中提取函數、結構體、枚舉型、共同體等的說明。當然，要正確提取源碼的注釋就必須要符合一定的規范。
規范見另外一篇博客：《Linux內核文檔：如何寫符合 kernel-doc 規范的注釋》
可以通過這樣子檢查是否符合規范：
$ ./scripts/kernel-doc -v -none <改動的.c/.h源碼文件>
根據提示，修正warning和error即可。
確定郵件接受人
不知道把郵件發給誰？別怕，Linux內核牛叉到有提供腳本獲取郵件接收人地址：
$ ./scripts/get_maintainer.pl 00*.patch
會比較慢，慢慢等，輸出結果參考如下：
Kees Cook <keescook@chromium.org> (maintainer:PSTORE FILESYSTEM)
Anton Vorontsov <anton@enomsg.org> (maintainer:PSTORE FILESYSTEM)
Colin Cross <ccross@android.com> (maintainer:PSTORE FILESYSTEM)
[...]
linux-doc@vger.kernel.org (open list:DOCUMENTATION)
linux-kernel@vger.kernel.org (open list)
linux-mtd@lists.infradead.org (open list:MEMORY TECHNOLOGY DEVICES (MTD))
因為我的是系列補丁，涉及多個子系統，所以獲取到的郵件地址很多。
上面顯示的地址中，很明顯最后linux-開頭的三行不是代碼reviewer，類似於訂閱轉發地址的存在。把郵件發給這幾個地址，就會轉發給所有訂閱了子系統的人。
發送郵件
我們用 git send-mail 發送郵件，簡單，舒心
git send-mail --to <maintainerA> --to <maintainerB> .... --cc linux-XXXX@xxxx --cc ... 00*.patch
把上面獲取的maintainer地址，用 --to 指定，訂閱地址改用抄送 --cc
當然，在這之前，需要在git中配置你的sendmail信息
$ cat ~/.gitconfig
[...]
[sendemail]
smtpserver = ...
smtpserverport = 465
smtpencryption = ssl
smtpuser = ...
響應質疑與等待合並
如果有maintainer對你的補丁有疑惑，別擔心，他們郵件提問，我們郵件回復。
郵件回復的細節不累述了。