當(dāng)Linux驅(qū)動程序開發(fā)到一定階段，向kernel.org提交代碼是一個很好的選擇。對于很多沒有向上游提交過代碼的開發(fā)者來說，還是有很多疑問需要解決的。比如，究竟我們向哪里提交驅(qū)動程序？提交時我們的代碼應(yīng)該處于什么狀態(tài)？提交的過程又如何呢？

[[143470]]

向哪里提交

Linux staging tree是Greg KH建立的用于提交驅(qū)動程序的git倉庫。我們可以把staging tree看作是代碼進入mainline內(nèi)核之前的一個預(yù)科班，新增的驅(qū)動程序首先需要放到這里供社區(qū)review和測試。Staging tree是 Greg KH于2008年建立的一棵kernel tree，其建立之目的是用來放置一些未充分測試或者因為一些其他原因未能進入內(nèi)核的新增驅(qū)動程序和新增文件系統(tǒng)。

Linux staging tree的URL是” git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git “或者” http://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git “。這里需要注意的是，git協(xié)議的端口號是9418，因為很多公司的防火墻只會開放80端口，clone代碼倉庫時如果git協(xié)議超時，不妨試試 http協(xié)議。

關(guān)于Linux staging tree更詳細的描述可以參考我前一篇博文《小議Linux staging tree》。

我們的代碼

在我們向上游提交驅(qū)動程序之前，需要保證代碼能夠遵循Linux內(nèi)核的coding style。當(dāng)然，這個規(guī)定并不是強制的，如果您經(jīng)常閱讀Linux內(nèi)核代碼，就會發(fā)現(xiàn)很多驅(qū)動對內(nèi)核coding style的遵循情況也并不是太好。但一致的代碼風(fēng)格對代碼的維護大有裨益，所以對作為Linux內(nèi)核驅(qū)動程序員的我們來說，遵循coding style是一個很好的習(xí)慣。關(guān)于Linux內(nèi)核的coding style的詳細信息，可以參考Linux內(nèi)核里的Documentation/CodingStyle文檔，或者我之前的博文《談?wù)劄?Linux 內(nèi)核開發(fā)驅(qū)動代碼的編碼風(fēng)格》。

我們在提交驅(qū)動之前還需要用靜態(tài)代碼檢查工具sparse來檢查一下代碼。

sparse的源代碼可以從“git://git.kernel.org/pub/scm/devel/sparse/sparse.git”獲 得，得到代碼之后，執(zhí)行”make; make install”來編譯生成可執(zhí)行程序。默認情況下，sparse程序會被放到目錄“~/bin”下面，如果您不喜歡這個位置，可以修改Makefile 來設(shè)定路徑。需要注意的是，使用sparse之前，PATH環(huán)境變量要設(shè)置正確。

sparse的使用方法很簡單，只要在make驅(qū)動程序時加上“C=N”的選項即可，其中N的取值是1或者2。當(dāng)N=1時表示對需要重新編譯的C文件進行代碼檢查，N=2時表示對所有的C文件進行代碼檢查。

對于staging目錄下的驅(qū)動來說，我們還需要附上一個TODO文件，用來描述未來的維護計劃。一般情況下，TODO文件可以這樣寫：

TODO:
- support more features
- use kernel coding style
- checkpatch.pl fixes

如何提交

我們可以通過patch的形式把驅(qū)動程序提交給staging tree。提交之前，需要首先把staging tree clone到本地，然后基于當(dāng)前的工作目錄制作patch。

Git提供了制作格式化的patch的功能，命令如下：

git format-patch -N

其中，N是整數(shù)，用來指定我們把最近N次提交做成N個patch。比如當(dāng)N=1時，就表示把最近一次提交制作成patch。Git會根據(jù)提交的log信息來自動命名patch文件。

這里需要注意的是，每次提交的log的描述要遵循一定的格式。

Log的第一行是一個簡短的描述。本文主要介紹如何向staging tree提交代碼，我們需要在Log首行以“staging:”開頭。Log的最后一行需要提供提交者的email信息，我們可以這樣 寫：“Signed-off-by: wwang <wwang@some.site>”。

舉個例子，假定我們的staging driver命名為hello_world，log的格式可以參考如下：

staging: hello_world: My first commit 
This is my first commit. 
Signed-off-by: wwang <wwang@some.site> 

Patch生成之后，我們需要把它寄給staging tree的維護者，通常是Greg KH本人以及l(fā)inux內(nèi)核驅(qū)動的開發(fā)者列表。這個步驟也可以使用git來幫助我們完成，但首先需要確定系統(tǒng)里已經(jīng)安裝msmtp和git-email這 兩個包。這里還需提醒一下，如果您的郵件服務(wù)器是Exchange，很可能需要NTLM認證，這就要求msmtp支持NTLM。Ubuntu倉庫里的 msmtp默認支持NTLM，可以直接使用，但還有些其他的發(fā)行版的軟件倉庫里自帶的msmtp并不支持NTLM（如Arch Linux），這種情況就需要自己編譯了。

msmtp安裝好之后，需要配置”~/.msmtprc”文件。以Gmail為例，”.msmtprc”可以這樣配置：

# Set default values for all following accounts. 
defaults 
logfile ~/.msmtp.log 
 
# gmail 
account gmail 
protocol smtp 
host smtp.gmail.com 
from my@gmail.com 
user my@gmail.com 
password mypasswd 
port 587 
auth on 
tls on 
tls_trust_file /etc/ssl/certs/ca-certificates.crt 
syslog LOG_MAIL 
 
# Set a default account 
account default : gmail 

用git發(fā)送patch的命令如下：

git send-email   /  
　　--smtp-server /usr/bin/msmtp  /  
　　--from my@gmail.com  / 
　　--to gregkh@suse.de  /  
　　--to devel@linuxdriverproject.org  /  
　　--to linux-kernel@vger.kernel.org  /  
　　./my.patch 

將patch發(fā)送出去只是提交驅(qū)動程序的第一步，之后還需要不斷的維護與完善，把代碼丟給內(nèi)核然后就放手不管的做法是不可取的。提交代碼還有一個原則，就是每次提交只做一件事情，這樣才會比較方便內(nèi)核維護者來review我們的代碼。