針對好多Linux 愛好者對內核很有興趣卻無從下手,本文旨在介紹一種解讀Linux內核源 碼的入門方法,而不是解說Linux復雜的內核機制。 1.核心源程序的文件組織 (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/i38 6/mm/Fault.c; ● Kernel:主要的核心代碼,此目錄下的文件實現了大多數Linux系統的內核函數,其 中最重要的文件當屬sched.c,同樣,和體系結構相關的代碼在arch/*/kernel中; ● Drivers:放置系統所有的設備驅動程序;每種驅動程序又各占用一個子目錄,如/bl ock下為塊設備驅動程序,比如ide(ide.c)。如果你希望查看所有可能包含文件系統的 設備是如何初始化的,你可以看drivers/block/genhd.c中的device_setup()。它不僅初 始化硬盤,也初始化網絡,因為安裝nfs文件系統的時候需要網絡。 其他如Lib放置核心的庫代碼; Net,核心與網絡相關的代碼;Ipc,這個目錄包含核心的 進程間通信的代碼;Fs ,所有的文件系統代碼和各種類型的文件操作代碼,它的每一個 子目錄支持一個文件系統,例如fat和ext2; Scripts, 此目錄包含用於配置核心的腳本 文件等。 一般在每個目錄下都有一個 .depend 文件和一個 Makefile 文件,這兩個文件都是編譯 時使用的輔助文件,仔細閱讀這兩個文件對弄清各個文件之間的聯系和依托關系很有幫 助,而且在有的目錄下還有Readme 文件,它是對該目錄下的文件的一些說明,同樣有利 於我們對內核源碼的理解。 2.解讀實戰:為你的內核增加一個系統調用 雖然Linux 的內核源碼用樹形結構組織得非常合理、科學,把功能相關聯的文件都放在 同一個子目錄下,這樣使得程序更具可讀性。然而,Linux 的內核源碼實在是太大而且 非常復雜,即便采用了很合理的文件組織方法,在不同目錄下的文件之間還是有很多的 關聯,分析核心的一部分代碼通常要查看其他的幾個相關的文件,而且可能這些文件還 不在同一個子目錄下。 體系的龐大復雜和文件之間關聯的錯綜復雜,可能就是很多人對其望而生畏的主要原因 。當然,這種令人生畏的勞動所帶來的回報也是非常令人著迷的:你不僅可以從中學到 很多的計算機的底層的知識(如下面將講到的系統的引導),體會到整個操作系統體系 結構的精妙和在解決某個具體細節問題時算法的巧妙,而且更重要的是在源碼的分析過 程中,你就會被一點一點地、潛移默化地專業化;甚至,只要分析1/10的代碼後,你就 會深刻地體會到,什麼樣的代碼才是一個專業的程序員寫的,什麼樣的代碼是一個業余 愛好者寫的。 為了使讀者能更好的體會到這一特點,下面舉了一個具體的內核分析實例,希望能通過 這個實例,使讀者對 Linux 的內核組織有些具體的認識,讀者從中也可以學到一些對內 核的分析方法。 以下即為分析實例: (1)操作平台 硬件:cpu intel Pentium II ; 軟件:Redhat Linux 6.0; 內核版本2.2.5 (2)相關內核源代碼分析 ① 系統的引導和初始化:Linux 系統的引導有好幾種方式,常見的有 Lilo、Loadin引 導和Linux的自舉引導(bootsect-loader),而後者所對應源程序為arch/i386/boot/bo otsect.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還要做一些其他的初始化工作。 ② 系統初始化後運行的第一個內核程序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就是中斷服務程序之一;vo id __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中。 ③ 中斷總控程序主要負責保存處理機執行系統調用前的狀態,檢驗當前調用是否合法,並 根據系統調用向量,使處理機跳轉到保存在 sys_call_table 表中的相應系統服務例程 的入口, 從系統服務例程返回後恢復處理機狀態退回用戶程序。 而系統調用向量則定義在/usr/src/linux/include/asm-386/unistd.h 中,sys_call_t able 表定義在 /usr/src/linux/arch/i386/kernel/entry.S 中, 同時在 /usr/src/l inux/include/asm-386/unistd.h 中也定義了系統調用的用戶編程接口。 ④ 由此可見 ,Linux 的系統調用也像 dos 系統的 int 21h 中斷服務, 它把0x80 中斷 作為總的入口, 然後轉到保存在 sys_call_table 表中的各種中斷服務例程的入口地址 , 形成各種不同的中斷服務。 由以上源代碼分析可知,要增加一個系統調用就必須在 sys_call_table 表中增加一項 ,並在其中保存好自己的系統服務例程的入口地址,然後重新編譯內核,當然,系統服務 例程是必不可少的。 由此可知,在此版Linux內核源程序<2.2.5>中,與系統調用相關的源程序文件就包括以下 這些: * arch/i386/boot/bootsect.S * arch/i386/Kernel/setup.S * arch/i386/boot/compressed/head.S * arch/i386/kernel/head.S * nit/main.c * rch/i386/kernel/traps.c * rch/i386/kernel/entry.S * rch/i386/kernel/irq.h * nclude/asm-386/unistd.h 當然,這只是涉及到的幾個主要文件。而事實上,增加系統調用真正要修改的文件只有 include/asm-386/unistd.h 和arch/i386/kernel/entry.S兩個。 (3)源碼的修改 ① 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 的累加值,然而也 可以把系統服務例程放在一個自己定義的文件或其他文件中,只是要在相應文件中作必 要的說明。 ②把smlinkage 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 ③把增加的 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 ④ 測試程序(test.c)如下: #include #include _syscall1(int,addtotal,int, num) main() { int i,j; do printf("Please input a number "); while(scanf("%d",&i)==EOF); if((j=addtotal(i))==-1) printf("Error occurred in syscall-addtotal(); "); printf("Total from 0 to %d is %d ",i,j); } 對修改後的新的內核進行編譯,並引導它作為新的操作系統,運行幾個程序後可以發現 一切正常;在新的系統下對測試程序進行編譯(注:由於原內核並未提供此系統調用,所 以只有在編譯後的新內核下,此測試程序才可能被編譯通過),運行情況如下: $gcc 杘 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),就可以達到增加系統調用的作用。 3.結束語 當然對於龐大復雜的 Linux而言,一篇文章遠遠不夠,而且與系統調用相關的代碼也只 是內核中極其微小的一部分,重要的是方法,掌握好的分析方法,所以上述分析只是起個引導作用,而真正的分析還有待讀者自己的努力。