Linux 內核解讀入門

class="21897"> 針對好多Linux　愛好者對內核很有興趣卻無從下口，本文旨在介紹一種解讀linux內核源碼的入門方法，
而不是解說linux復雜的內核機制；
一．核心源程序的文件組織：　
1．Linux核心源程序通常都安裝在/usr/src/linux下，而且它有一個非常簡單的編號約定：任何偶數的
核心（例如2.0.30）都是一個穩定地發行的核心，而任何奇數的核心（例如2.1.42）都是一個開發中的核心。
本文基於穩定的2.2.5源代碼，第二部分的實現平台為　Redhat　Linux　6.0。
2．核心源程序的文件按樹形結構進行組織，在源程序樹的最上層你會看到這樣一些目錄：
●Arch　：arch子目錄包括了所有和體系結構相關的核心代碼。它的每一個子目錄都代表一種支持的體系
　　結構，例如i386就是關於intel　cpu及與之相兼容體系結構的子目錄。PC機一般都基於此目錄；
●Include:　include子目錄包括編譯核心所需要的大部分頭文件。與平台無關的頭文件在　include/linux
　　子目錄下，與　intel　cpu相關的頭文件在include/asm-i386子目錄下,而include/scsi目錄則是有關
　　scsi設備的頭文件目錄；
●Init：　這個目錄包含核心的初始化代碼(注：不是系統的引導代碼)，包含兩個文件main.c和Version.c，
　　這是研究核心如何工作的一個非常好的起點。
●Mm　：這個目錄包括所有獨立於　cpu　體系結構的內存管理代碼，如頁式存儲管理內存的分配和釋放等；而和
　　體系結構相關的內存管理代碼則位於arch/*/mm/，例如arch/i386/mm/Fault.c
●Kernel：主要的核心代碼，此目錄下的文件實現了大多數linux系統的內核函數，其中最重要的文件當屬
　　sched.c；同樣，和體系結構相關的代碼在arch/*/kernel中；
●Drivers：　放置系統所有的設備驅動程序;每種驅動程序又各占用一個子目錄：如，/block　下為塊設備
　　驅動程序，比如ide（ide.c）。如果你希望查看所有可能包含文件系統的設備是如何初始化的，你可以看
　　drivers/block/genhd.c中的device_setup()。它不僅初始化硬盤，也初始化網絡，因為安裝nfs文件
　　系統的時候需要網絡
其他:　　如,　Lib放置核心的庫代碼;　Net,核心與網絡相關的代碼;　Ipc,這個目錄包含核心的進程間通訊的代碼;　
　　Fs　,所有的文件系統代碼和各種類型的文件操作代碼，它的每一個子目錄支持一個文件系統，例如fat和ext2;
　　Scripts,　此目錄包含用於配置核心的腳本文件等。
　　　一般，在每個目錄下，都有一個　.depend　文件和一個　Makefile　文件，這兩個文件都是編譯時
　　使用的輔助文件，仔細閱讀這兩個文件對弄清各個文件這間的聯系和依托關系很有幫助；而且，在有的目錄下
　　還有Readme　文件，它是對該目錄下的文件的一些說明，同樣有利於我們對內核源碼的理解；
　　
二．解讀實戰：為你的內核增加一個系統調用
雖然，Linux　的內核源碼用樹形結構組織得非常合理、科學，把功能相關聯的文件都放在同一個子目錄下，這樣使
得程序更具可讀性。然而，Linux　的內核源碼實在是太大而且非常復雜，即便采用了很合理的文件組織方法，在
不同目錄下的文件之間還是有很多的關聯，分析核心的一部分代碼通常會要查看其它的幾個相關的文件，而且可能
這些文件還不在同一個子目錄下。
體系的龐大復雜和文件之間關聯的錯綜復雜，可能就是很多人對其望而生畏的主要原因。當然，這種令人生畏的勞動
所帶來的回報也是非常令人著迷的：你不僅可以從中學到很多的計算機的底層的知識（如下面將講到的系統的引導），
體會到整個操作系統體系結構的精妙和在解決某個具體細節問題時，算法的巧妙；而且更重要的是：在源碼的分析過
程中，你就會被一點一點地、潛移默化地專業化；甚至，只要分析十分之一的代碼後，你就會深刻地體會到，什麼樣
的代碼才是一個專業的程序員寫的，什麼樣的代碼是一個業余愛好者寫的。
為了使讀者能更好的體會到這一特點，下面舉了一個具體的內核分析實例，希望能通過這個實例，使讀者對　Linux　
的內核的組織有些具體的認識，從中讀者也可以學到一些對內核的分析方法。

以下即為分析實例：

【一】操作平台:
硬件：cpu　　　　　　　　　　　　　　　　　　　　intel　Pentium　II　;
軟件：Redhat　Linux　6.0;　　　　　　內核版本2.2.5

【二】相關內核源代碼分析:
1．系統的引導和初始化：Linux　系統的引導有好幾種方式：常見的有　Lilo,　Loadin引導和Linux的自舉引導
　　（bootsect-loader）,而後者所對應源程序為arch/i386/boot/bootsect.S，它為實模式的匯編程序，限於
　　　篇幅在此不做分析；無論是哪種引導方式，最後都要跳轉到　　arch/i386/Kernel/setup.S，　setup.S主要是
　　　進行時模式下的初始化，為系統進入保護模式做准備；此後，系統執行　arch/i386/kernel/head.S　(對經壓縮
　　　後存放的內核要先執行　arch/i386/boot/compressed/head.S);　head.S　中定義的一段匯編程序setup_idt　，
　　　它負責建立一張256項的　idt　表(Interrupt　Descriptor　Table),此表保存著所有自陷和中斷的入口地址;其中
　　　包括系統調用總控程序　system_call　的入口地址;當然，除此之外，head.S還要做一些其他的初始化工作；
2．系統初始化後運行的第一個內核程序asmlinkage　void　__init　start_kernel(void)　定義在
　　　/usr/src/linux/init/main.c中,它通過調用usr/src/linux/arch/i386/kernel/traps.c　　中的一個函數　
　　　void　__init　trap_init(void)　把各自陷和中斷服務程序的入口地址設置到　idt　表中,其中系統調用總控程序
　　　　system_cal就是中斷服務程序之一;void　__init　trap_init(void)　　　函數則通過調用一個宏　
　　　　set_system_gate(SYSCALL_VECTOR,&system_call);　把系統調用總控程序的入口掛在中斷0x80上;
其中SYSCALL_VECTOR是定義在　/usr/src/linux/arch/i386/kernel/irq.h中的一個常量0x80;　　而　system_call　
　即為中斷總控程序的入口地址;中斷總控程序用匯編語言定義在/usr/src/linux/arch/i386/kernel/entry.S中;
3.中斷總控程序主要負責保存處理機執行系統調用前的狀態,檢驗當前調用是否合法,　並根據系統調用向量，使處理機
　　跳轉到保存在　sys_call_table　表中的相應系統服務例程的入口;　從系統服務例程返回後恢復處理機狀態退回用戶程序;
　　而系統調用向量則定義在/usr/src/linux/include/asm-386/unistd.h　　中;sys_call_table　表定義在
　　/usr/src/linux/arch/i386/kernel/entry.S　中; 　同時在　/usr/src/linux/include/asm-386/unistd.h　
　　中也定義了系統調用的用戶編程接口;
4.由此可見　,　　linux　的系統調用也象　dos　系統的　　int　21h　中斷服務,　　它把0x80　中斷作為總的入口,　然後
　　轉到保存在　sys_call_table　表中的各種中斷服務例程的入口地址　,　形成各種不同的中斷服務;
　　由以上源代碼分析可知,　　要增加一個系統調用就必須在　sys_call_table　　表中增加一項　,　　並在其中保存好自己
　　的系統服務例程的入口地址,然後重新編譯內核，當然，系統服務例程是必不可少的。
由此可知在此版linux內核源程序<2。2。5>中,與系統調用相關的源程序文件就包括以下這些:
1．arch/i386/boot/bootsect.S
2．arch/i386/Kernel/setup.S
3．arch/i386/boot/compressed/head.S
4．arch/i386/kernel/head.S
5．init/main.c
6．arch/i386/kernel/traps.c
7．arch/i386/kernel/entry.S
8．arch/i386/kernel/irq.h
9．include/asm-386/unistd.h

　當然，這只是涉及到的幾個主要文件。而事實上，增加系統調用真正要修改文件只有include/asm-386/unistd.h
　和arch/i386/kernel/entry.S兩個;

【三】　對內核源碼的修改：
1.在kernel/sys.c中增加系統服務例程如下：
　　　　　 　asmlinkage　int　sys_addtotal(int　numdata)
{
int　i=0,enddata=0;
while(i<=numdata)
enddata+=i++;
return　enddata;
}
　　該函數有一個　int　型入口參數　numdata　,　並返回從　0　到　numdata　的累加值;　　當然也可以把系統服務例程放
　　在一個自己定義的文件或其他文件中，只是要在相應文件中作必要的說明；
2.把　asmlinkage　int　sys_addtotal(　int)　的入口地址加到sys_call_table表中:
　　arch/i386/kernel/entry.S　中的最後幾行源代碼修改前為:　
...　　　...
.long　SYMBOL_NAME(sys_sendfile)
.long　SYMBOL_NAME(sys_ni_syscall) /*　streams1　*/
.long　SYMBOL_NAME(sys_ni_syscall) /*　streams2　*/
.long　SYMBOL_NAME(sys_vfork)　　　　　　　　　　　　/*　190　*/
.rept　NR_syscalls-190
.long　SYMBOL_NAME(sys_ni_syscall)
.endr
修改後為:　 ...　　　...
.long　SYMBOL_NAME(sys_sendfile)
.long　SYMBOL_NAME(sys_ni_syscall) /*　streams1　*/
.long　SYMBOL_NAME(sys_ni_syscall) /*　streams2　*/
.long　SYMBOL_NAME(sys_vfork)　　　　　　　　　　　　/*　190　*/
/*　add　by　I　*/
.long　SYMBOL_NAME(sys_addtotal)
.rept　NR_syscalls-191
.long　SYMBOL_NAME(sys_ni_syscall)
.endr
3.　把增加的　sys_call_table　表項所對應的向量,在include/asm-386/unistd.h　中進行必要申明,以供
　　　用戶進程和其他系統進程查詢或調