Linux 核心解讀入門 (轉)

Linux 核心解讀入門 (轉)[@more@]

針對好多 愛好者對核心很有興趣卻無從下口，本文旨在介紹一種解讀linux核心原始碼的方法，而不是解說linux複雜的核心機制；

一．核心源的組織：

1．Linux核心源程式通常都在/usr/src/linux下，而且它有一個非常簡單的編號約定：任何偶數的核心（例如2.0.30）都是一個穩定地發行的核心，而任何奇數的核心（例如2.1.42）都是一個開發中的核心。

本文基於穩定的2.2.5，第二部分的實現平臺為 Linux 6.0。

2．核心源程式的檔案按樹形結構進行組織，在源程式樹的最上層你會看到這樣一些目錄：

●Arch ：arch子目錄包括了所有和體系結構相關的核心程式碼。它的每一個子目錄都代表一種支援的體系結構，例如i386就是關於 及與之相相容體系結構的子目錄。PC機一般都基於此目錄；

●Include: include子目錄包括編譯核心所需要的大部分標頭檔案。與平臺無關的標頭檔案在 include/linux子目錄下，與 intel cpu相關的標頭檔案在include/asm-i386子目錄下,而include/目錄則是有關scsi裝置的標頭檔案目錄；

●Init：這個目錄包含核心的初始化程式碼(注：不是的引導程式碼)，包含兩個檔案main.c和Version.c，這是研究核心如何工作的一個非常好的起點。

●Mm ：這個目錄包括所有獨立於 cpu 體系結構的管理程式碼，如頁式管理記憶體的分配和釋放等；而和體系結構相關的記憶體管理程式碼則位於arch/*/mm/，例如arch/i386/mm/Fault.c

●Kernel：主要的核心程式碼，此目錄下的檔案實現了大多數linux系統的核心，其中最重要的檔案當屬sched.c；同樣，和體系結構相關的程式碼在arch/*/kernel中；

●s：放置系統所有的裝置程式;每種驅動程式又各佔用一個子目錄：如，/block 下為塊裝置驅動程式，比如（ide.c）。如果你希望檢視所有可能包含檔案系統的裝置是如何初始化的，你可以看drivers/block/genhd.c中的device_setup()。它不僅初始化，也初始化，因為安裝nfs檔案系統的時候需要網路其他: 如, Lib放置核心的庫程式碼;,核心與網路相關的程式碼; Ipc,這個目錄包含核心的程式間通訊的程式碼; Fs ,所有的檔案系統程式碼和各種型別的檔案操作程式碼，它的每一個子目錄支援一個檔案系統，例如和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 的系統呼叫也象 d系統的 int 21h 中斷服務, 它把0x80 中斷作為總的入口, 然後轉到儲存在 sys_call_table 表中的各種中斷服務例程的入口地址 , 形成各種不同的中斷服務;

由以上原始碼分析可知, 要增加一個系統呼叫就必須在 sys_call_table 表中增加一項 , 並在其中儲存好自己的系統服務例程的入口地址,然後重新編譯核心，當然，系統服務例程是必不可少的。

由此可知在此版linux核心源程式中,與系統呼叫相關的源程式檔案就包括以下這些:

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 中進行必要申明,以供使用者程式和其他系統程式查詢或呼叫:

增加後的部分 /usr/src/linux/include/asm-386/unistd.h 檔案如下:

... ...

#define __NR_sendfile 187

#define __NR_getpmsg 188

#define __NR_putpmsg 189

#define __NR_vfork 190

/* add by I */

#define __NR_addtotal 191

4.測試程式(test.c)如下:

#include

#include

_syscall1(int,addtotal,int, num)

main()

{

int i,j;


　　do

printf("Please input a numbern");

while(scanf("%d",&i)==EOF);

if((j=addtotal(i))==-1)

printf("Error occurred in syscall-addtotal();n");

printf("Total from 0 to %d is %d n",i,j);

}

對修改後的新的核心進行編譯，並引導它作為新的作業系統，執行幾個程式後可以發現一切正常；在新的系統下對測試程式進行編譯(*注：由於原核心並未提供此係統呼叫，所以只有在編譯後的新核心下，此測試程式才能可能被編譯透過)，執行情況如下：

$gcc -o test test.c

$./test

Please input a number

36

Total from 0 to 36 is 666

可見，修改成功；

而且，對相關原始碼的進一步分析可知，在此版本的核心中,從/usr/src/linux/arch/i386/kernel/entry.S

檔案中對 sys_call_table 表的設定可以看出,有好幾個系統呼叫的服務例程都是定義在/usr/src/linux/kernel/sys.c 中的同一個函式：

asmlinkage int sys_ni_syscall(void)

{

return -ENOSYS;

}

例如第188項和第189項就是如此:

... ...

.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 */

... ...

而這兩項在檔案 /usr/src/linux/include/asm-386/unistd.h 中卻申明如下:

... ...

#define __NR_sendfile 187

#define __NR_getpmsg 188 /* some people actually want streams */

#define __NR_putpmsg 189 /* some people actually want streams */

#define __NR_vfork 190

由此可見,在此版本的核心原始碼中,由於asmlinkage int sys_ni_syscall(void) 函式並不進行任何操作,所以包括 getpmsg, putpmsg 在內的好幾個系統呼叫都是不進行任何操作的，即有待擴充的空呼叫；但它們卻仍然佔用著sys_call_table表項，估計這是設計者們為了方便擴充系統呼叫而安排的; 所以只需增加相應服務例程（如增加服務例程getmsg或putpmsg），就可以達到增加系統呼叫的作用。

結語：當然對於龐大複雜的 linux 核心而言，一篇文章遠遠不夠，而且與系統呼叫相關的程式碼也只是核心中極其微小的一部分；但重要的是方法、掌握好的分析方法；所以上的分析只是起個引導的作用，而正真的分析還有待於讀者自己的努力。:) 　　　　 有空去我們的站Patching Heroes　 　
　　　　　　　 　
　計算機是一門只靠書本和自己上機就能掌握的技能　 AIJAGBDGPOEAJCCHJBEBGD/xici/board/board.asp?id=2463">也是俠