自動(dòng)測(cè)試工具

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

AuToTest

AuToTest 是一個(gè)全自動(dòng)測(cè)試框架，存在的主要目的就是測(cè)試 Linux 內(nèi)核，當(dāng)然也可以用來測(cè)試其他東西，比如測(cè)試一塊新硬件是否能穩(wěn)定工作。AuToTest 是開源軟件，以 GPL 方式授權(quán)，運(yùn)行于 server-client 架構(gòu)（即 C/S 架構(gòu)）。你可以通過配置 server 端來對(duì)運(yùn)行了 client 端的系統(tǒng)執(zhí)行初始化、運(yùn)行與監(jiān)測(cè)工作，也可以自己在目標(biāo)系統(tǒng)上讓 client 運(yùn)行起來。另外你可以為這個(gè)測(cè)試框架添加測(cè)試用例，詳情請(qǐng)參考AuToTest 白皮書。

Linaro Automated Validation Architecture

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

顯示 LAVA 支持的測(cè)試列表：

lava-test list-tests 

安裝測(cè)試套件：

lava-test install ltp 

運(yùn)行測(cè)試：

lava-test run ltp 

查看結(jié)果：

lava-test results show ltp-timestamp.0 

卸載測(cè)試套件：

lava-test uninstall ltp 

內(nèi)核調(diào)試功能

Linux 內(nèi)核本身包含很多調(diào)試功能，比如 kmemcheck 和 kmemleak。

[[118997]]

kmemcheck

kmemcheck 是一個(gè)動(dòng)態(tài)檢查工具，可以檢測(cè)出一些未被初始化的內(nèi)存（LCTT：內(nèi)核態(tài)使用這些內(nèi)存可能會(huì)造成系統(tǒng)崩潰）并發(fā)出警告。它的功能與 Valgrind 類似，只是 Valgrind 運(yùn)行在用戶態(tài)，而 kmemchecke 運(yùn)行在內(nèi)核態(tài)。編譯內(nèi)核時(shí)加上 CONFIG_KMEMCHECK 選項(xiàng)打開 kmemcheck 調(diào)試功能。你可以閱讀 Documentation/kmemcheck.txt 來學(xué)習(xí)如何配置使用這個(gè)功能，以及如何看懂調(diào)試結(jié)果。

kmemleak

kmemleak 通過類似于垃圾收集器的功能來檢測(cè)內(nèi)核是否有內(nèi)存泄漏問題。而 kmemleak 與垃圾收集器的不同之處在于前者不會(huì)釋放孤兒目標(biāo)（LCTT：不會(huì)再被使用的、應(yīng)該被釋放而沒被釋放的內(nèi)存區(qū)域），而是將它們打印到 /sys/kernel/debug/kmemleak 文件中。用戶態(tài)的 Valgrind 也有一個(gè)類似的功能，使用 --leak-check 選項(xiàng)可以檢測(cè)并報(bào)錯(cuò)內(nèi)存泄漏問題，但并不釋放這個(gè)孤兒內(nèi)存。編譯內(nèi)核時(shí)使用 CONFIG_DEBUG_KMEMLEAK 選項(xiàng)打開 kmemcleak 調(diào)試功能。閱讀 Documentation/kmemleak.txt 來學(xué)習(xí)怎么使用這個(gè)工具并讀懂調(diào)試結(jié)果。

內(nèi)核調(diào)試接口

Linux 內(nèi)核通過配置選項(xiàng)、調(diào)試用的 API、接口和框架來支持動(dòng)態(tài)或靜態(tài)的調(diào)試。我們現(xiàn)在就好好學(xué)習(xí)學(xué)習(xí)這些牛逼的功能，從靜態(tài)編譯選項(xiàng)開始講。

調(diào)試配置選項(xiàng)：靜態(tài)編譯

大部分 Linux 內(nèi)核以及內(nèi)核模塊都包含調(diào)試選項(xiàng)，你只要在編譯內(nèi)核或內(nèi)核模塊的時(shí)候添加這個(gè)靜態(tài)調(diào)試選項(xiàng)，程序運(yùn)行時(shí)后就會(huì)產(chǎn)生調(diào)試信息，并記錄在 dmesg 緩存中。

調(diào)試的 API

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

#p#

動(dòng)態(tài)調(diào)試

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

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

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

讓內(nèi)核模塊在加載過程中打開動(dòng)態(tài)調(diào)試功能：

使用 modprobe 命令加在模塊時(shí)加上 dyndbg='plmft' 選項(xiàng)。

讓內(nèi)核模塊的動(dòng)態(tài)調(diào)試功能在重啟后依然有效：

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

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

設(shè)置追蹤點(diǎn)

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

詳細(xì)信息請(qǐng)參考布置追蹤代碼的小技巧。

“追蹤點(diǎn)”的原理

追蹤點(diǎn)使用“跳躍標(biāo)簽”，這是一種使用分支跳轉(zhuǎn)的編碼修正（code modification）技術(shù)。

當(dāng)關(guān)閉追蹤點(diǎn)的時(shí)候，其偽代碼看起來時(shí)這樣的：

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

當(dāng)打開追蹤點(diǎn)的時(shí)候，其偽代碼看起來時(shí)這樣的：（注意追蹤點(diǎn)代碼出現(xiàn)的位置）

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

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

Linux 電源管理子系統(tǒng)的測(cè)試

使用靜態(tài)調(diào)試、動(dòng)態(tài)調(diào)試和追蹤調(diào)試技術(shù)，我們來跑一下磁盤的電源管理測(cè)試。當(dāng)系統(tǒng)被掛起時(shí)，內(nèi)核會(huì)為磁盤創(chuàng)建一個(gè)休眠鏡像，使磁盤進(jìn)入休眠模式，當(dāng)系統(tǒng)重新被喚醒時(shí)，內(nèi)核又利用這個(gè)休眠鏡像重新喚醒磁盤。

設(shè)置掛起設(shè)備與喚醒設(shè)備需要的時(shí)間：

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 模式掛起磁盤 —— 能測(cè)試更多內(nèi)容，比如 BIOS 掛起和喚醒，會(huì)涉及到 ACPI 功能。我們推薦你使用這種方式，把 BIOS 也拉下水陪你玩掛起和喚醒游戲。

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

#p#

Linux 內(nèi)核補(bǔ)丁測(cè)試

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

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

• linux_git/Documentation
• linux_git/tools/testing
• 交叉編譯參考：在 x86_64 架構(gòu)上交叉編譯 Linux 內(nèi)核：初學(xué)者教程

如果你對(duì)你的補(bǔ)丁測(cè)試結(jié)果感到很滿意，你就可以提交補(bǔ)丁了。請(qǐng)確保提交 commit 的信息要描述得非常清楚。要讓內(nèi)核維護(hù)者和其他開發(fā)者看懂補(bǔ)丁所修改的內(nèi)容，這一點(diǎn)非常重要。生成補(bǔ)丁后，執(zhí)行 scripts/checkpatch.pl 腳本，找到 checkpatch 是產(chǎn)生的錯(cuò)誤或警告（如果有的話），修復(fù)它們。重新生成補(bǔ)丁，直到補(bǔ)丁通過這個(gè)腳本的測(cè)試。重新測(cè)試這個(gè)補(bǔ)丁。將本補(bǔ)丁用于其他的內(nèi)核源碼上，保證不會(huì)有沖突產(chǎn)生。

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

更多提交補(bǔ)丁的規(guī)矩，請(qǐng)參考下面的資料：

• 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

下面是一些內(nèi)核測(cè)試教程的資料：

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

內(nèi)核測(cè)試套件和項(xiàng)目

除我們討論過的測(cè)試資源之外，這里還有很多測(cè)試項(xiàng)目值得介紹，包括開源的和廠家自己提供的。這些項(xiàng)目每一個(gè)都是針對(duì)特定領(lǐng)域的，比如嵌入式或者企業(yè)自己使用。我們簡(jiǎn)單過一下。

Linux 測(cè)試項(xiàng)目（LTP）測(cè)試套件是一系列工具的集合，用于測(cè)試內(nèi)核的可靠性、健壯性和穩(wěn)定性。你可以為這個(gè)項(xiàng)目添加自己的測(cè)試代碼，并且 LTP 項(xiàng)目歡迎你貢獻(xiàn)自己的代碼。runltp 腳本默認(rèn)情況下會(huì)測(cè)試下面的子系統(tǒng)：

• 文件系統(tǒng)壓力測(cè)試
• 磁盤 IO 測(cè)試
• 內(nèi)存管理壓力測(cè)試
• IPC（進(jìn)程間通信）測(cè)試
• 調(diào)度器測(cè)試
• 命令的功能性驗(yàn)證測(cè)試
• 系統(tǒng)調(diào)用功能驗(yàn)證測(cè)試

LTP-DDT 是一個(gè)基于 LTP 的測(cè)試應(yīng)用（LCTT：就是 LTP 的閹割版么），專注于測(cè)試嵌入式設(shè)備驅(qū)動(dòng)。

Linux Driver Verification 這個(gè)項(xiàng)目的目標(biāo)是提高 Linux 設(shè)備驅(qū)動(dòng)的質(zhì)量，它為設(shè)備驅(qū)動(dòng)驗(yàn)證開發(fā)了集成環(huán)境平臺(tái)，并且利用與時(shí)俱進(jìn)的研究來增強(qiáng)驗(yàn)證工具的質(zhì)量。

一致性測(cè)試

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

靜態(tài)分析工具

靜態(tài)分析之所以會(huì)被稱為“靜態(tài)分析”，是因?yàn)檫@些工具只分析代碼，并不執(zhí)行它們。分析 Linux 內(nèi)核代碼的靜態(tài)分析工具有很多，Sparse 是 Linus Torvalds 寫的專門用于檢查內(nèi)核靜態(tài)類型的工具。它是一個(gè)語義檢查器，會(huì)為 C 語言的語義建立語義檢析樹，執(zhí)行惰性類型評(píng)估。內(nèi)核編譯系統(tǒng)支持 sparse，并且為編譯內(nèi)核的命令提供開啟 sparse 的選項(xiàng)。

為內(nèi)核所有需要重新編譯的 C 文件執(zhí)行 sparse 語義檢查：

make C=1 allmodconfig

為內(nèi)核所有 C 文件（即使不需要重新編譯）執(zhí)行 sparse 語義檢查：

make C=2 allmodconfig

Sparse 的資源：

• Sparse Archive
• Sparse How To

Smatch 分析程序代碼的邏輯錯(cuò)誤。它可以檢測(cè)到諸如“為一個(gè)沒鎖上的 spinlock 執(zhí)行解鎖”的邏輯錯(cuò)誤。內(nèi)核源碼支持 smatch：

在 Linux 內(nèi)核中運(yùn)行 smatch：

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

請(qǐng)參考下面的資料來獲取和編譯 smatch。需要注意的是 smatch 是個(gè)正在發(fā)展的項(xiàng)目，架構(gòu)會(huì)不斷變化。

• Smatch

那么我們?cè)撛趺刺幚?Sparse 和 Smatch 所發(fā)現(xiàn)的語義和邏輯上的錯(cuò)誤呢？一些錯(cuò)誤可以被分離為日常問題或模塊問題，可以輕易被解決。但是有些語義錯(cuò)誤涉及到全局，因?yàn)榧羟姓迟N了一些代碼。在一些環(huán)境中，當(dāng)一些接口函數(shù)被廢棄不再使用，或者僅僅做了寫微小的修改，你就需要大規(guī)模更新源碼。這時(shí)候你需要 Coccinelle 來幫忙。，Coccinelle 使用 SmPL 語言（語義包語言）來為 C 代碼提供匹配和轉(zhuǎn)換代碼的功能。Coccinelle 的從一開始就作為 Linux 的附屬產(chǎn)品持續(xù)發(fā)展的。

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

參考文獻(xiàn)

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

• 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