Linux內核解讀入門(mén)

針對好多Linux 愛(ài)好者對內核很有興趣卻無(wú)從下口，本文旨在介紹一種解讀linux內核源碼的入門(mén)方法，而不是解說(shuō)linux復雜的內核機制；

一．核心源程序的文件組織：

1．Linux核心源程序通常都安裝在/usr/src/linux下，而且它有一個(gè)非常簡(jiǎn)單的編號約定：任何偶數的核心（例如2.0.30）都是一個(gè)穩定地發(fā)行的核心，而任何奇數的核心（例如2.1.42）都是一個(gè)開(kāi)發(fā)中的核心。

本文基于穩定的2.2.5源代碼，第二部分的實(shí)現平臺為 Redhat Linux 6.0。

2．核心源程序的文件按樹(shù)形結構進(jìn)行組織，在源程序樹(shù)的最上層你會(huì )看到這樣一些目錄：

●Arch ：arch子目錄包括了所有和體系結構相關(guān)的核心代碼。它的每一個(gè)子目錄都代表一種支持的體系結構，例如i386就是關(guān)于intel cpu及與之相兼容體系結構的子目錄。PC機一般都基于此目錄；

●Include: include子目錄包括編譯核心所需要的大部分頭文件。與平臺無(wú)關(guān)的頭文件在 include/linux子目錄下，與 intel cpu相關(guān)的頭文件在include/asm-i386子目錄下,而include/scsi目錄則是有關(guān)scsi設備的頭文件目錄；

●Init： 這個(gè)目錄包含核心的初始化代碼(注：不是系統的引導代碼)，包含兩個(gè)文件main.c和Version.c，這是研究核心如何工作的一個(gè)非常好的起點(diǎn)。

●Mm ：這個(gè)目錄包括所有獨立于 cpu 體系結構的內存管理代碼，如頁(yè)式存儲管理內存的分配和釋放等；而和體系結構相關(guān)的內存管理代碼則位于arch/*/mm/，例如arch/i386/mm/Fault.c

●Kernel：主要的核心代碼，此目錄下的文件實(shí)現了大多數linux系統的內核函數，其中最重要的文件當屬sched.c；同樣，和體系結構相關(guān)的代碼在arch/*/kernel中；

●Drivers： 放置系統所有的設備驅動(dòng)程序;每種驅動(dòng)程序又各占用一個(gè)子目錄：如，/block 下為塊設備驅動(dòng)程序，比如ide（ide.c）。如果你希望查看所有可能包含文件系統的設備是如何初始化的，你可以看drivers/block/genhd.c中的device_setup()。它不僅初始化硬盤(pán)，也初始化網(wǎng)絡(luò )，因為安裝nfs文件系統的時(shí)候需要網(wǎng)絡(luò )其他: 如, Lib放置核心的庫代碼; Net,核心與網(wǎng)絡(luò )相關(guān)的代碼; Ipc,這個(gè)目錄包含核心的進(jìn)程間通訊的代碼; Fs ,所有的文件系統代碼和各種類(lèi)型的文件操作代碼，它的每一個(gè)子目錄支持一個(gè)文件系統，例如fat和ext2;

scripts, 此目錄包含用于配置核心的腳本文件等。

一般，在每個(gè)目錄下，都有一個(gè) .depend 文件和一個(gè) Makefile 文件，這兩個(gè)文件都是編譯時(shí)使用的輔助文件，仔細閱讀這兩個(gè)文件對弄清各個(gè)文件這間的聯(lián)系和依托關(guān)系很有幫助；而且，在有的目錄下還有Readme 文件，它是對該目錄下的文件的一些說(shuō)明，同樣有利于我們對內核源碼的理解；
　　
二．解讀實(shí)戰：為你的內核增加一個(gè)系統調用

雖然，Linux 的內核源碼用樹(shù)形結構組織得非常合理、科學(xué)，把功能相關(guān)聯(lián)的文件都放在同一個(gè)子目錄下，這樣使得程序更具可讀性。然而，Linux 的內核源碼實(shí)在是太大而且非常復雜，即便采用了很合理的文件組織方法，在不同目錄下的文件之間還是有很多的關(guān)聯(lián)，分析核心的一部分代碼通常會(huì )要查看其它的幾個(gè)相關(guān)的文件，而且可能這些文件還不在同一個(gè)子目錄下。

體系的龐大復雜和文件之間關(guān)聯(lián)的錯綜復雜，可能就是很多人對其望而生畏的主要原因。當然，這種令人生畏的勞動(dòng)所帶來(lái)的回報也是非常令人著(zhù)迷的：你不僅可以從中學(xué)到很多的計算機的底層的知識（如下面將講到的系統的引導），體會(huì )到整個(gè)操作系統體系結構的精妙和在解決某個(gè)具體細節問(wèn)題時(shí)，算法的巧妙；而且更重要的是：在源碼的分析過(guò)程中，你就會(huì )被一點(diǎn)一點(diǎn)地、潛移默化地專(zhuān)業(yè)化；甚至，只要分析十分之一的代碼后，你就會(huì )深刻地體會(huì )到，什么樣的代碼才是一個(gè)專(zhuān)業(yè)的程序員寫(xiě)的，什么樣的代碼是一個(gè)業(yè)余愛(ài)好者寫(xiě)的。

為了使讀者能更好的體會(huì )到這一特點(diǎn)，下面舉了一個(gè)具體的內核分析實(shí)例，希望能通過(guò)這個(gè)實(shí)例，使讀者對 Linux的內核的組織有些具體的認識，從中讀者也可以學(xué)到一些對內核的分析方法。
以下即為分析實(shí)例：

【一】操作平臺:

硬件：cpu intel Pentium II

軟件：Redhat Linux 6.0; 內核版本2.2.5【二】相關(guān)內核源代碼分析:

1．系統的引導和初始化：Linux 系統的引導有好幾種方式：常見(jiàn)的有 Lilo, Loadin引導和Linux的自舉引導
（bootsect-loader）,而后者所對應源程序為arch/i386/boot/bootsect.S，它為實(shí)模式的匯編程序，限于篇幅在此不做分析；無(wú)論是哪種引導方式，最后都要跳轉到 arch/i386/Kernel/setup.S， setup.S主要是進(jìn)行時(shí)模式下的初始化，為系統進(jìn)入保護模式做準備；此后，系統執行 arch/i386/kernel/head.S (對經(jīng)壓縮后存放的內核要先執行 arch/i386/boot/compressed/head.S); head.S 中定義的一段匯編程序setup_idt ，它負責建立一張256項的 idt 表(Interrupt Descriptor Table),此表保存著(zhù)所有自陷和中斷的入口地址;其中包括系統調用總控程序 system_call 的入口地址;當然，除此之外，head.S還要做一些其他的初始化工作；

2．系統初始化后運行的第一個(gè)內核程序asmlinkage void __init start_kernel(void) 定義在
/usr/src/linux/init/main.c中,它通過(guò)調用usr/src/linux/arch/i386/kernel/traps.c 中的一個(gè)函數
void __init trap_init(void) 把各自陷和中斷服務(wù)程序的入口地址設置到 idt 表中,其中系統調用總控程序system_cal就是中斷服務(wù)程序之一;void __init trap_init(void) 函數則通過(guò)調用一個(gè)宏set_system_gate(SYSCALL_VECTOR,system_call); 把系統調用總控程序的入口掛在中斷0x80上; 其中SYSCALL_VECTOR是定義在 /usr/src/linux/arch/i386/kernel/irq.h中的一個(gè)常量0x80; 而 system_call 即為中斷總控程序的入口地址;中斷總控程序用匯編語(yǔ)言定義在/usr/src/linux/arch/i386/kernel/entry.S中;

3.中斷總控程序主要負責保存處理機執行系統調用前的狀態(tài),檢驗當前調用是否合法, 并根據系統調用向量，使處理機跳轉到保存在 sys_call_table 表中的相應系統服務(wù)例程的入口; 從系統服務(wù)例程返回后恢復處理機狀態(tài)退回用戶(hù)程序;
而系統調用向量則定義在/usr/src/linux/include/asm-386/unistd.h 中;sys_call_table 表定義在/usr/src/linux/arch/i386/kernel/entry.S 中; 同時(shí)在 /usr/src/linux/include/asm-386/unistd.h 中也定義了系統調用的用戶(hù)編程接口;

4.由此可見(jiàn) , linux 的系統調用也象 dos 系統的 int 21h 中斷服務(wù), 它把0x80 中斷作為總的入口, 然后轉到保存在 sys_call_table 表中的各種中斷服務(wù)例程的入口地址 , 形成各種不同的中斷服務(wù);
由以上源代碼分析可知, 要增加一個(gè)系統調用就必須在 sys_call_table 表中增加一項 , 并在其中保存好自己的系統服務(wù)例程的入口地址,然后重新編譯內核，當然，系統服務(wù)例程是必不可少的。
由此可知在此版linux內核源程序中,與系統調用相關(guān)的源程序文件就包括以下這些:

1．a(chǎn)rch/i386/boot/bootsect.S
2．a(chǎn)rch/i386/Kernel/setup.S
3．a(chǎn)rch/i386/boot/compressed/head.S
4．a(chǎn)rch/i386/kernel/head.S
5．init/main.c
6．a(chǎn)rch/i386/kernel/traps.c
7．a(chǎn)rch/i386/kernel/entry.S
8．a(chǎn)rch/i386/kernel/irq.h
9．include/asm-386/unistd.h

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

【三】 對內核源碼的修改：

1.在kernel/sys.c中增加系統服務(wù)例程如下：

asmlinkage int sys_addtotal(int numdata)
{
int i=0,enddata=0;
while(i=numdata)
enddata+=i++;
return enddata;
}

該函數有一個(gè) int 型入口參數 numdata , 并返回從 0 到 numdata 的累加值; 當然也可以把系統服務(wù)例程放在一個(gè)自己定義的文件或其他文件中，只是要在相應文件中作必要的說(shuō)明；

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 中進(jìn)行必要申明,以供用戶(hù)進(jìn)程和其他系統進(jìn)程查詢(xún)或調用:

增加后的部分 /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);
}

對修改后的新的內核進(jìn)行編譯，并引導它作為新的操作系統，運行幾個(gè)程序后可以發(fā)現一切正常；在新的系統下對測試程序進(jìn)行編譯(*注：由于原內核并未提供此系統調用，所以只有在編譯后的新內核下，此測試程序才能可能被編譯通過(guò))，運行情況如下：

$gcc -o test test.c
$./test
Please input a number
36
Total from 0 to 36 is 666

可見(jiàn)，修改成功；

而且，對相關(guān)源碼的進(jìn)一步分析可知，在此版本的內核中,從/usr/src/linux/arch/i386/kernel/entry.S
文件中對 sys_call_table 表的設置可以看出,有好幾個(gè)系統調用的服務(wù)例程都是定義在/usr/src/linux/kernel/sys.c 中的同一個(gè)函數：

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

由此可見(jiàn),在此版本的內核源代碼中,由于asmlinkage int sys_ni_syscall(void) 函數并不進(jìn)行任何操作,所以包括 getpmsg, putpmsg 在內的好幾個(gè)系統調用都是不進(jìn)行任何操作的，即有待擴充的空調用； 但它們卻仍然占用著(zhù)sys_call_table表項，估計這是設計者們?yōu)榱朔奖銛U充系統調用而安排的; 所以只需增加相應服務(wù)例程（如增加服務(wù)例程getmsg或putpmsg），就可以達到增加系統調用的作用。

結語(yǔ)：當然對于龐大復雜的 linux 內核而言，一篇文章遠遠不夠，而且與系統調用相關(guān)的代碼也只是內核中極其微小的一部分；但重要的是方法、掌握好的分析方法；所以上的分析只是起個(gè)引導的作用，而正真的分析還有待于讀者自己的努力。:)