這些技巧都是平時我自已在閱讀的時候總結的，想到哪就說到哪了，其實我總結的技巧遠不止這些，但是先說這些吧。後面想到了再補充，只有在拿到程式碼做分析的時候遇到實際的問題時，才能見招拆招，想些辦法。
其實linux核心原始碼還是比較難跟蹤的，我剛開始閱讀核心原始碼的時候，感覺很多東西經常找著找著就失去頭緒了，很鬱悶。
通過一些閱讀後發現核心也就那麼幾招用的比較多，摸清楚其脾氣後，剩下的就是耐心了。
1.我曾經用過一陣VI,裝了一堆外掛後折騰了一陣，發現還是無法感受其推崇者所說的那一堆好處，還是喜歡用sourceinsight。好了，說正題了。首先我們要解決的就是函式或者變數找不到定義地方的問題，表現在sourceinsight上就是那個變數是黑的，到處找不到。
比如我們看們看到：
int bus_register(struct bus_type * bus)
{
 ...
 subsys_set_kset(bus, bus_subsys);
 retval = subsystem_register(&bus->subsys);
 ...
}
其中的bus_subsys。
找了一下bus_subsys找不到定義的地方，肯定是核心和我們躲貓貓，這時候我們可以是否查詢一些明顯的“定義痕跡”，比如在bus_subsys中的subsys或者說_subsys。果然有新發現。我們找到了這麼一個巨集。
#define decl_subsys(_name,_type,_uevent_ops) /
struct subsystem _name##_subsys = { /
 .kset = { /
  .kobj = { .name = __stringify(_name) }, /
  .ktype = _type, /
  .uevent_ops =_uevent_ops, /
 } /
}
得，我們回過頭在包含有bus_register的原始檔及標頭檔案中查詢一下，果然找到了static decl_subsys(bus, &ktype_bus, NULL);這麼一行程式碼。
像這種東西我不是很建議一找不到就直接去網上找，關於核心的文章網上雖然很多，但都不會細到所有的細節都有，你總有獨立處理問題的時候，為什麼我們不提前讓自已多鍛鍊一下呢？
2.順序問題，核心有很多的順序，比如初始化的順序，比如我們有module_init,__initcall等等，一來編譯的時候資料夾和檔案有順序，另外不同的巨集包含的東西順序也是有講究的，所以在分析模組的時候一定要注意這個，這個東西只能說是注意了，如果對一個模組不熟悉的時候，不可能做到全部都瞭解，像我有時候也會落下一些東西忘記分析，但是隨著看核心的時候越久，核心那些慣用的手法見多了後，就發現不外如是，也就那三瓜子兩棗。

3.我們要解決核心執行時那一堆指來指去的指標的問題。這個是我自已除錯用的土方法，我就用dump_stack在關鍵的地方打印出順序就行了。因為我們做的是嵌入式裝置，很多時候不能用KGDB這些高階工具線上調，而且這種方法基本不增加其它的效能開銷。

4.有多個定義不知道用哪個。這個基本是因為LINUX支援的CPU比較多造成的。
我們可以用GDB靜態分析，也可以用objdump和nm等工具來精確定位一些函式和變數，也可以根據巨集來一步一步分析，比如是mips的那麼我們就進mips看，這樣一步一步來。

5.具備一些意識，你現在面對的是作業系統，不僅僅是隻有C檔案和標頭檔案的應用，MAKEFILE，連結檔案，Kconfig都應該是你的朋友。尤其在看一個模組或者一小部分你感興趣的程式碼的時候，首先可以用MAKEFILE和KCONFIG來縮小你需要關注的範圍。其實關於MAKEFILE和KCONFIG的重要性，fudan_abc在他那個LINUX那些事之我是USB中強調的比較多，但是說實話，fudan_abc那文章看了玩是挺好玩的，可惜感覺好像看了沒啥用，就是知道了一堆概念，不能串起來，我不知道是我的理解能力不行，還是任僑偉同志壓根沒有講清楚。呵呵。