自動測試工具

這里列出一些能滿足不同需求的測試工具供你選擇。本小節只是簡單介紹個大概，并不提供詳細操作指南。

AuToTest

AuToTest 是一個全自動測試框架，存在的主要目的就是測試 Linux 內核，當然也可以用來測試其他東西，比如測試一塊新硬件是否能穩定工作。AuToTest 是開源軟件，以 GPL 方式授權，運行于 server-client 架構（即 C/S 架構）。你可以通過配置 server 端來對運行了 client 端的系統執行初始化、運行與監測工作，也可以自己在目標系統上讓 client 運行起來。另外你可以為這個測試框架添加測試用例，詳情請參考AuToTest 白皮書。

Linaro Automated Validation Architecture

LAVA 自動測試框架用于自動安裝于運行測試。舉個例子：你在 LAVA 里面只需運行幾個命令就可以跑 LTP（LCTT：Linux Test Project，中文是 Linux 測試計劃，SGI發起并由IBM負責維護，目的是為開源社區提供測試套件來驗證Linux的可靠性、健壯性和穩定性）。通過 LAVA 命令可以自動為你安裝 LTP 所需要的所有依賴包，下載源碼、編譯編碼、將 LTP 安裝到某個獨立的地方，方便卸載 LTP 時能移除所有二進制文件。安裝好 LTP 后，運行 LAVA 命令時添加 'ltp' 選項就可以運行 LTP 測試任務了，它會將測試結果以文件方式保存下來，文件名包含測試名稱、時間戳。這些測試結果可以留著供以后參考。這是個發現軟件退化（如果軟件退化了的話）的好方法。下面列出 LAVA 配合 LTP 使用的一些命令：

顯示 LAVA 支持的測試列表：

lava-test list-tests 

安裝測試套件：

lava-test install ltp 

運行測試：

lava-test run ltp 

查看結果：

lava-test results show ltp-timestamp.0 

卸載測試套件：

lava-test uninstall ltp 

內核調試功能

Linux 內核本身包含很多調試功能，比如 kmemcheck 和 kmemleak。

[[118997]]

kmemcheck

kmemcheck 是一個動態檢查工具，可以檢測出一些未被初始化的內存（LCTT：內核態使用這些內存可能會造成系統崩潰）并發出警告。它的功能與 Valgrind 類似，只是 Valgrind 運行在用戶態，而 kmemchecke 運行在內核態。編譯內核時加上 CONFIG_KMEMCHECK 選項打開 kmemcheck 調試功能。你可以閱讀 Documentation/kmemcheck.txt 來學習如何配置使用這個功能，以及如何看懂調試結果。

kmemleak

kmemleak 通過類似于垃圾收集器的功能來檢測內核是否有內存泄漏問題。而 kmemleak 與垃圾收集器的不同之處在于前者不會釋放孤兒目標（LCTT：不會再被使用的、應該被釋放而沒被釋放的內存區域），而是將它們打印到 /sys/kernel/debug/kmemleak 文件中。用戶態的 Valgrind 也有一個類似的功能，使用 --leak-check 選項可以檢測并報錯內存泄漏問題，但并不釋放這個孤兒內存。編譯內核時使用 CONFIG_DEBUG_KMEMLEAK 選項打開 kmemcleak 調試功能。閱讀 Documentation/kmemleak.txt 來學習怎么使用這個工具并讀懂調試結果。

內核調試接口

Linux 內核通過配置選項、調試用的 API、接口和框架來支持動態或靜態的調試。我們現在就好好學習學習這些牛逼的功能，從靜態編譯選項開始講。

調試配置選項：靜態編譯

大部分 Linux 內核以及內核模塊都包含調試選項，你只要在編譯內核或內核模塊的時候添加這個靜態調試選項，程序運行時后就會產生調試信息，并記錄在 dmesg 緩存中。

調試的 API

調試 API 的一個很好的例子是 DMA-debug，用來調試驅動是否錯誤使用了 DMA 提供的 API。它會跟蹤每個設備的映射關系，檢測程序有沒有試圖為一些根本不存在的映射執行“取消映射”操作，檢測代碼建立 DMA 映射后可能產生的“映射丟失”的錯誤。內核配置選項 CONFIG_HAVE_DMA_APT_DEBUG 和 CONFIG_DMA_API_DEBUG 可以為內核提供這個功能。其中，CONFIG_DMA_API_DEBUG 選項啟用后，內核調用 DMA 的 API 的同時也會調用 Debug-dma 接口。舉例來說，當一個驅動調用 dma_map_page() 函數來映射一個 DMA 緩存時，dma_map_page() 會調用debug_dma_map_page() 函數來跟蹤這個緩存，直到驅動調用 dma_unmap_page() 來取消映射。詳細內容請參考使用 DMA 調試 API 檢測潛在的數據污染和內存泄漏問題。

#p#

動態調試

動態調試功能就是你可以決定在程序運行過程中是否要 pr_debug(), dev_dbg(), print_hex_dump_debug(), print_hex_dump_bytes() 這些函數正常運行起來。什么意思？當程序運行過程中出現錯誤時，你可以指定程序打印有針對性的、詳細的調試信息。這功能牛逼極了，我們不再需要為了添加調試代碼定位一個問題，而重新編譯安裝內核。你可以指定 CONDIF_DYNAMIC_DEBUG 選項打開動態調試功能，然后通過 /sys/kernel/debug/dynamic_debug/control 接口指定要打印哪些調試日志。下面分別列出代碼級別和模塊級別打印日志的操作方法：

讓 kernel/power/suspend.c 源碼第340行的 pr_debug() 函數打印日志：

echo 'file suspend.c line 340 +p' > /sys/kernel/debug/dynamic_debug/control

讓內核模塊在加載過程中打開動態調試功能：

使用 modprobe 命令加在模塊時加上 dyndbg='plmft' 選項。

讓內核模塊的動態調試功能在重啟后依然有效：

編輯 /etc/modprobe.d/modname.conf 文件（沒有這個文件就創建一個），添加 dyndbg='plmft' 選項。然而對于哪些通過 initramfs 加載的驅動來說，這個配置基本無效（LCTT：免費奉送點比較高級的知識哈。系統啟動時，需要先讓 initramfs 掛載一個虛擬的文件系統，然后再掛載啟動盤上的真實文件系統。這個虛擬文件系統里面的文件是 initramfs 自己提供的，也就是說你在真實的文件系統下面配置了 /etc/modprobe.d/modname.conf 這個文件，initramfs 是壓根不去理會的。站在內核驅動的角度看：如果內核驅動在 initramfs 過程中被加載到內核，這個驅動讀取到的 /etc/modprobe.d/modname.conf 是 initramfs 提供的，而不是你編輯的那個。所以會有上述“寫了配置文件后重啟依然無效”的結論）。對于這種刁民，呃，刁驅動，我們需要修改 grub 配置文件，在 kernel 那一行添加 module.dyndbg='plmft' 參數，這樣你的驅動就可以開機啟動動態調試功能了。

想打印更詳細的調試信息，可以使用 dynamic_debug.verbose=1 選項。參考 Documentation/dynamic-debug-howto.txt 文件獲取更多信息。

設置追蹤點

到目前為止，我們介紹了多種動態和靜態調試方法。靜態調試選項和靜態調試鉤子函數（比如 DMA Debug API）需要的編譯過程打開或關閉，導致了一個難過的事實：需要重新編譯安裝內核。而動態編譯功能省去了“重新編譯”這件麻煩事，但是也有不足的地方，就是調試代碼引入了條件變量，用于判斷是否打印調試信息。這種方法可以讓你在程序運行時決定是否打印日志，但需要執行額外的判斷過程。“追蹤點”代碼只會在程序運行過程中使用“追蹤點”功能才會被觸發。也就是說，“追蹤點”代碼與上述說的兩種方法都不一樣。當用不到它時，它不會運行（LCTT：動態調試的話，代碼每次都需要查看下變量，然后判斷是否需要打印日志；而“追蹤點”貌似利用某種觸發機制，不需要每次都去查看變量）。當你需要用到它時，程序的代碼會把“追蹤點”代碼包含進去。它不會添加任何條件變量來增加系統的運行負擔。

詳細信息請參考布置追蹤代碼的小技巧。

“追蹤點”的原理

追蹤點使用“跳躍標簽”，這是一種使用分支跳轉的編碼修正（code modification）技術。

當關閉追蹤點的時候，其偽代碼看起來時這樣的：

[ code1 ]
nop
back:
[ code2 ]
return;
tracepoint:
[ tracepoint code ]
jmp back;

當打開追蹤點的時候，其偽代碼看起來時這樣的：（注意追蹤點代碼出現的位置）

[ code1 ]
jmp tracepoint
back:
[ code2 ]
return;
tracepoint:
[ tracepoint code ]
jmp back;

（LCTT：咳咳，解釋解釋上面兩段偽代碼吧，能看懂的大神請忽略這段注釋。不使用追蹤點時，代碼運行過程是：code1->code2->return結束；使用追蹤點時，代碼運行過程是：code1->跳到tracepoint code執行調試代碼->跳回code2->return結束。兩段代碼的唯一區別就是第二行，前者為 nop（不做任何操作），后者為 jmp tracepoint （跳到調試代碼）。）

Linux 電源管理子系統的測試

使用靜態調試、動態調試和追蹤調試技術，我們來跑一下磁盤的電源管理測試。當系統被掛起時，內核會為磁盤創建一個休眠鏡像，使磁盤進入休眠模式，當系統重新被喚醒時，內核又利用這個休眠鏡像重新喚醒磁盤。

設置掛起設備與喚醒設備需要的時間：

echo 1 > /sys/power/pm_print_times

以 reboot 模式掛起磁盤：

echo reboot > /sys/power/disk
echo disk > /sys/power/state

以 shutdown 模式掛起磁盤 —— 與 reboot 模式一樣，只是重新喚醒磁盤的話還需要電源提供。

echo shutdown > /sys/power/disk
echo disk > /sys/power/state

以 platform 模式掛起磁盤 —— 能測試更多內容，比如 BIOS 掛起和喚醒，會涉及到 ACPI 功能。我們推薦你使用這種方式，把 BIOS 也拉下水陪你玩掛起和喚醒游戲。

echo platform > /sys/power/disk
echo disk > /sys/power/state

#p#

Linux 內核補丁測試

你試過自己寫內核補丁嗎？本節介紹在把你的補丁包提交到 Linux 郵箱列表之前，需要做哪些操作。另外我們還會介紹如何把它發送出去。

寫好代碼后，編譯它。把 make 過程產生的輸出保存到文檔中，查看新代碼有沒有警告信息。找到所有的警告信息，處理掉。當你的代碼編譯過程沒有任何不正常的輸出，安裝這個內核，然后啟動測試。如果啟動正常，查看 dmesg 里面有沒于錯誤，與老內核生成的 dmesg 日志做個比較。運行一些壓力測試，請參考我們以前講過的測試內容。如果這個補丁用于修復某個 bug，請確保真的已經修復了。如果真的修復了，請確保能通過系統測試。找出打你補丁的模塊下面的回歸測試工具，運行一下。如果補丁涉及到其他架構，你需要交叉編譯然后測試一下。請通過下面的目錄查找測試工具：

• linux_git/Documentation
• linux_git/tools/testing
• 交叉編譯參考：在 x86_64 架構上交叉編譯 Linux 內核：初學者教程

如果你對你的補丁測試結果感到很滿意，你就可以提交補丁了。請確保提交 commit 的信息要描述得非常清楚。要讓內核維護者和其他開發者看懂補丁所修改的內容，這一點非常重要。生成補丁后，執行 scripts/checkpatch.pl 腳本，找到 checkpatch 是產生的錯誤或警告（如果有的話），修復它們。重新生成補丁，直到補丁通過這個腳本的測試。重新測試這個補丁。將本補丁用于其他的內核源碼上，保證不會有沖突產生。

現在你做好提交補丁的準備了。先運行 scriptst/get_maintainer.pl 來確認你應該把補丁發給哪個內核維護者。注意不要以附件形式發送補丁，而是以純文本形式粘貼在郵件里面。確保你的郵件客戶端可以發送純文本信息，你可以試試給自己發送一份補丁郵件來測試你的郵件客戶端的功能。收到自己的郵件后，運行 checkpatch 命令并給自己的內核源碼打上你的補丁。如果這兩部都能通過，你就可以給 Linux 郵箱列表發送補丁了。使用 git send-email 命令是提交補丁最安全的方式，可以避免你的郵箱的兼容性問題。你的 .gitconfig 文件里面需要配置好有效的 smtp 服務器，詳細操作參考 git 的幫助文檔。

更多提交補丁的規矩，請參考下面的資料：

• linux_git/Documentation/applying-patches.txt
• linux_git/Documentation/SubmitChecklist
• linux_git/Documentation/SubmittingDrivers
• linux_git/Documentation/SubmittingPatches
• linuxgit/Documentation/stablekernel_rules.txt
• linuxgit/Documentation/stableapi_nonsense.txt

下面是一些內核測試教程的資料：

• USB Testing on Linux
• Linux Kernel Tester's Guide Chapter2
• Linux Kernel Tester's Guide
• Testing resources at eLinux.org
• eLinux Debugging Portal

內核測試套件和項目

除我們討論過的測試資源之外，這里還有很多測試項目值得介紹，包括開源的和廠家自己提供的。這些項目每一個都是針對特定領域的，比如嵌入式或者企業自己使用。我們簡單過一下。

Linux 測試項目（LTP）測試套件是一系列工具的集合，用于測試內核的可靠性、健壯性和穩定性。你可以為這個項目添加自己的測試代碼，并且 LTP 項目歡迎你貢獻自己的代碼。runltp 腳本默認情況下會測試下面的子系統：

• 文件系統壓力測試
• 磁盤 IO 測試
• 內存管理壓力測試
• IPC（進程間通信）測試
• 調度器測試
• 命令的功能性驗證測試
• 系統調用功能驗證測試

LTP-DDT 是一個基于 LTP 的測試應用（LCTT：就是 LTP 的閹割版么），專注于測試嵌入式設備驅動。

Linux Driver Verification 這個項目的目標是提高 Linux 設備驅動的質量，它為設備驅動驗證開發了集成環境平臺，并且利用與時俱進的研究來增強驗證工具的質量。

一致性測試

如果你有將某個 Unix 平臺下的應用一直到另一個平臺的經驗，你就能理解 Linux Standard Base (LSB) 和 LSB 一致性測試套件的重要性了。LSB 是 Linux Foundation 工作組創建的用于降低支持不同 Linux 平臺所需要的開銷，方法就是通過降低不同 Linux 發行版之間的差別，保證應用在不同發行版之間的可移植性。前事不忘后事之師，Unix 世界的分歧在 Linux 世界一定要避免。這就是為什么你可以把一個 rpm 包轉化成 deb 包后還能安裝并正常運行的秘密。

靜態分析工具

靜態分析之所以會被稱為“靜態分析”，是因為這些工具只分析代碼，并不執行它們。分析 Linux 內核代碼的靜態分析工具有很多，Sparse 是 Linus Torvalds 寫的專門用于檢查內核靜態類型的工具。它是一個語義檢查器，會為 C 語言的語義建立語義檢析樹，執行惰性類型評估。內核編譯系統支持 sparse，并且為編譯內核的命令提供開啟 sparse 的選項。

為內核所有需要重新編譯的 C 文件執行 sparse 語義檢查：

make C=1 allmodconfig

為內核所有 C 文件（即使不需要重新編譯）執行 sparse 語義檢查：

make C=2 allmodconfig

Sparse 的資源：

• Sparse Archive
• Sparse How To

Smatch 分析程序代碼的邏輯錯誤。它可以檢測到諸如“為一個沒鎖上的 spinlock 執行解鎖”的邏輯錯誤。內核源碼支持 smatch：

在 Linux 內核中運行 smatch：

make CHECK="~/path/to/smatch/smatch -p=kernel" C=1 bzImage modules | tee warns.txt

請參考下面的資料來獲取和編譯 smatch。需要注意的是 smatch 是個正在發展的項目，架構會不斷變化。

• Smatch

那么我們該怎么處理 Sparse 和 Smatch 所發現的語義和邏輯上的錯誤呢？一些錯誤可以被分離為日常問題或模塊問題，可以輕易被解決。但是有些語義錯誤涉及到全局，因為剪切粘貼了一些代碼。在一些環境中，當一些接口函數被廢棄不再使用，或者僅僅做了寫微小的修改，你就需要大規模更新源碼。這時候你需要 Coccinelle 來幫忙。，Coccinelle 使用 SmPL 語言（語義包語言）來為 C 代碼提供匹配和轉換代碼的功能。Coccinelle 的從一開始就作為 Linux 的附屬產品持續發展的。

舉個例子：foo(int) 函數突然變成 foo(int, char *) 函數，多出了一個輸入參數（可以把第二個參數置為 null）。所有調用 foo() 函數的代碼都需要更新了，這可能是個悲摧的體力活。但是使用 Coccinelle 的話，這項工作瞬間變得輕松，腳本會幫你找到調用 foo(parameter1) 的代碼，然后替換成 foo(parameter1, NULL)。做完這些后，所有調用這個函數的代碼都可以運行一遍，驗證下第二個參數為 NULL 是否能正常工作。關于 Coccinelle 的更多信息，以及在不同項目中（當然，也包括 Linux 內核這個項目）的使用方法，請參考項目主頁：Cocinelle。

參考文獻

本文涵蓋了很多方面，這里列出一些參考文檔供讀者做進一步研究。

• KernelHacking
• kernel Documentation
• Linux Device Drivers, Third Edition
• Dynamic Event Tracing in Linux Kernel
• Kernel Testing: Tool and Techniques

原文鏈接：http://linux.cn/article-3682-1.html   http://linux.cn/article-3684-1.html