這些技巧都是平時我自已在閱讀的時候總結的，想到哪就說到哪了，其實我總結的技巧遠不止這些，但是先說這些吧。后面想到了再補充，只有在拿到代碼做分析的時候遇到實際的問題時，才能見招拆招，想些辦法。
其實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那文章看了玩是挺好玩的，可惜感覺好像看了沒啥用，就是知道了一堆概念，不能串起來，我不知道是我的理解能力不行，還是任僑偉同志壓根沒有講清楚。呵呵。