一種解讀linux內(nèi)核源碼的入門方法 -- 未審核linux 內(nèi)核解讀入門 針對好多Linux 愛好者對內(nèi)核很有興趣卻無從下口，本文旨在介紹一種解讀linux內(nèi)核源碼的入門方法，而不是解說linux復(fù)雜的內(nèi)核機(jī)制； 一．核心源程序的文件組織： 1．Linux核心源程序通常都安裝在/usr/src/linux下，而且它有一個非常簡單的編號約定：任何偶數(shù)的核心（例如2.0.30）都是一個穩(wěn)定地發(fā)行的核心，而任何奇數(shù)的核心（例如2.1.42）都是一個開發(fā)中的核心。 本文基于穩(wěn)定的2.2.5源代碼，第二部分的實現(xiàn)平臺為 Redhat Linux 6.0。 2．核心源程序的文件按樹形結(jié)構(gòu)進(jìn)行組織，在源程序樹的最上層你會看到這樣一些目錄： ●Arch ：arch子目錄包括了所有和體系結(jié)構(gòu)相關(guān)的核心代碼。它的每一個子目錄都代表一種支持的體系結(jié)構(gòu)，例如i386就是關(guān)于intel cpu及與之相兼容體系結(jié)構(gòu)的子目錄。PC機(jī)一般都基于此目錄； ●Include: include子目錄包括編譯核心所需要的大部分頭文件。與平臺無關(guān)的頭文件在 include/linux子目錄下，與 intel cpu相關(guān)的頭文件在include/asm-i386子目錄下,而include/scsi目錄則是有關(guān)scsi設(shè)備的頭文件目錄； ●Init： 這個目錄包含核心的初始化代碼(注：不是系統(tǒng)的引導(dǎo)代碼)，包含兩個文件main.c和Version.c，這是研究核心如何工作的一個非常好的起點(diǎn)。 ●Mm ：這個目錄包括所有獨(dú)立于 cpu 體系結(jié)構(gòu)的內(nèi)存管理代碼，如頁式存儲管理內(nèi)存的分配和釋放等；而和體系結(jié)構(gòu)相關(guān)的內(nèi)存管理代碼則位于arch/*/mm/，例如arch/i386/mm/Fault.c ●Kernel：主要的核心代碼，此目錄下的文件實現(xiàn)了大多數(shù)linux系統(tǒng)的內(nèi)核函數(shù)，其中最重要的文件當(dāng)屬sched.c；同樣，和體系結(jié)構(gòu)相關(guān)的代碼在arch/*/kernel中； ●Drivers： 放置系統(tǒng)所有的設(shè)備驅(qū)動程序;每種驅(qū)動程序又各占用一個子目錄：如，/block 下為塊設(shè)備驅(qū)動程序，比如ide（ide.c）。如果你希望查看所有可能包含文件系 統(tǒng)的設(shè)備是如何初始化的，你可以看drivers/block/genhd.c中的device_setup()。它不僅初始化硬盤，也初始化網(wǎng)絡(luò)，因為 安裝nfs文件系統(tǒng)的時候需要網(wǎng)絡(luò)其他: 如, Lib放置核心的庫代碼; Net,核心與網(wǎng)絡(luò)相關(guān)的代碼; Ipc,這個目錄包含核心的進(jìn)程間通訊的代碼; Fs ,所有的文件系統(tǒng)代碼和各種類型的文件操作代碼，它的每一個子目錄支持一個文件系統(tǒng)，例如fat和ext2; Scripts, 此目錄包含用于配置核心的腳本文件等。 一般，在每個目錄下，都有一個 .depend 文件和一個 Makefile 文件，這兩個文件都是編譯時使用的輔助文件，仔細(xì)閱讀這兩個文件對弄清各個文件這間的聯(lián)系和依托關(guān)系很有幫助；而且，在有的目錄下還有Readme 文件，它是對該目錄下的文件的一些說明，同樣有利于我們對內(nèi)核源碼的理解； 二．解讀實戰(zhàn)：為你的內(nèi)核增加一個系統(tǒng)調(diào)用 雖然，Linux 的內(nèi)核源碼用樹形結(jié)構(gòu)組織得非常合理、科學(xué)，把功能相關(guān)聯(lián)的文件都放在同一個子目錄下，這樣使得程序更具可讀性。然而，Linux 的內(nèi)核源碼實在是太大而且非常復(fù)雜，即便采用了很合理的文件組織方法，在不同目錄下的文件之間還是有很多的關(guān)聯(lián)，分析核心的一部分代碼通常會要查看其它的幾個相關(guān)的文件，而且可能這些文件還不在同一個子目錄下。 體系的龐大復(fù)雜和文件之間關(guān)聯(lián)的錯綜復(fù)雜，可能就是很多人對其望而生畏的主要原因。 當(dāng)然，這種令人生畏的勞動所帶來的回報也是非常令人著迷的：你不僅可以從中學(xué)到很多的計算機(jī)的底層的知識（如下面將講到的系統(tǒng)的引導(dǎo)），體會到整個操作系 統(tǒng)體系結(jié)構(gòu)的精妙和在解決某個具體細(xì)節(jié)問題時，算法的巧妙；而且更重要的是：在源碼的分析過程中，你就會被一點(diǎn)一點(diǎn)地、潛移默化地專業(yè)化；甚至，只要分析 十分之一的代碼后，你就會深刻地體會到，什么樣的代碼才是一個專業(yè)的程序員寫的，什么樣的代碼是一個業(yè)余愛好者寫的。 為了使讀者能更好的體會到這一特點(diǎn)，下面舉了一個具體的內(nèi)核分析實例，希望能通過這個實例，使讀者對 Linux的內(nèi)核的組織有些具體的認(rèn)識，從中讀者也可以學(xué)到一些對內(nèi)核的分析方法。 以下即為分析實例： 【一】操作平臺: 硬件：cpu intel Pentium II ; 軟件：Redhat Linux 6.0; 內(nèi)核版本2.2.5【二】相關(guān)內(nèi)核源代碼分析: 1．系統(tǒng)的引導(dǎo)和初始化：Linux 系統(tǒng)的引導(dǎo)有好幾種方式：常見的有 Lilo, Loadin引導(dǎo)和Linux的自舉引導(dǎo)（bootsect-loader）,而后者所對應(yīng)源程序為arch/i386/boot/bootsect.S，它為實模式的匯編程序，限于篇幅在此不做分析；無論是哪種引導(dǎo)方式，最后都要跳轉(zhuǎn)到 arch/i386/Kernel/setup.S， setup.S主要是進(jìn)行時模式下的初始化，為系統(tǒng)進(jìn)入保護(hù)模式做準(zhǔn)備；此后，系統(tǒng)執(zhí)行 arch/i386/kernel/head.S (對經(jīng)壓縮后存放的內(nèi)核要先執(zhí)行 arch/i386/boot/compressed/head.S); head.S 中定義的一段匯編程序setup_idt ，它負(fù)責(zé)建立一張256項的 idt 表(Interrupt Descriptor Table),此表保存著所有自陷和中斷的入口地址;其中包括系統(tǒng)調(diào)用總控程序 system_call 的入口地址;當(dāng)然，除此之外，head.S還要做一些其他的初始化工作； 2．系統(tǒng)初始化后運(yùn)行的第一個內(nèi)核程序asmlinkage void __init start_kernel(void) 定義在 /usr/src/linux/init/main.c中,它通過調(diào)用usr/src/linux/arch/i386/kernel/traps.c 中的一個函數(shù) void __init trap_init(void) 把各自陷和中斷服務(wù)程序的入口地址設(shè)置到 idt 表中,其中系統(tǒng)調(diào)用總控程序system_cal就是中斷服務(wù)程序之一;void __init trap_init(void) 函數(shù)則通過調(diào)用一個宏 set_system_gate(SYSCALL_VECTOR,&system_call); 把系統(tǒng)調(diào)用總控程序的入口掛在中斷0x80上; 其中SYSCALL_VECTOR是定義在 /usr/src/linux/arch/i386/kernel/irq.h中的一個常量0x80; 而 system_call 即為中斷總控程序的入口地址;中斷總控程序用匯編語言定義在/usr/src/linux/arch/i386/kernel/entry.S中; 3.中斷總控程序主要負(fù)責(zé)保存處理機(jī)執(zhí)行系統(tǒng)調(diào)用前的狀態(tài),檢驗當(dāng)前調(diào)用是否合法, 并根據(jù)系統(tǒng)調(diào)用向量，使處理機(jī)跳轉(zhuǎn)到保存在 sys_call_table 表中的相應(yīng)系統(tǒng)服務(wù)例程的入口; 從系統(tǒng)服務(wù)例程返回后恢復(fù)處理機(jī)狀態(tài)退回用戶程序; 而系統(tǒng)調(diào)用向量則定義在/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 中也定義了系統(tǒng)調(diào)用的用戶編程接口; 4.由此可見 , linux 的系統(tǒng)調(diào)用也象 dos 系統(tǒng)的 int 21h 中斷服務(wù), 它把0x80 中斷作為總的入口, 然后轉(zhuǎn)到保存在 sys_call_table 表中的各種中斷服務(wù)例程的入口地址 , 形成各種不同的中斷服務(wù); 由以上源代碼分析可知, 要增加一個系統(tǒng)調(diào)用就必須在 sys_call_table 表中增加一項 , 并在其中保存好自己的系統(tǒng)服務(wù)例程的入口地址,然后重新編譯內(nèi)核，當(dāng)然，系統(tǒng)服務(wù)例程是必不可少的。 由此可知在此版linux內(nèi)核源程序中,與系統(tǒng)調(diào)用相關(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 當(dāng)然，這只是涉及到的幾個主要文件。而事實上，增加系統(tǒng)調(diào)用真正要修改文件只有include/asm-386/unistd.h和arch/i386/kernel/entry.S兩個; 【三】 對內(nèi)核源碼的修改： 1.在kernel/sys.c中增加系統(tǒng)服務(wù)例程如下： C/C++代碼
當(dāng)然也可以把系統(tǒng)服務(wù)例程放在一個自己定義的文件或其他文件中，只是要在相應(yīng)文件中作必要的說明； 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 表項所對應(yīng)的向量,在include/asm-386/unistd.h 中進(jìn)行必要申明,以供用戶進(jìn)程和其他系統(tǒng)進(jìn)程查詢或調(diào)用: 增加后的部分 /usr/src/linux/include/asm-386/unistd.h 文件如下: ... ... C/C++代碼
$gcc -o test test.c $./test Please input a number 36 Total from 0 to 36 is 666 可見，修改成功； 而且，對相關(guān)源碼的進(jìn)一步分析可知，在此版本的內(nèi)核中,從/usr/src/linux/arch/i386/kernel/entry.S 文件中對 sys_call_table 表的設(shè)置可以看出,有好幾個系統(tǒng)調(diào)用的服務(wù)例程都是定義在/usr/src/linux/kernel/sys.c 中的同一個函數(shù)： 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 由此可見,在此版本的內(nèi)核源代碼中,由于asmlinkage int sys_ni_syscall(void) 函數(shù)并不進(jìn)行任何操作,所以包括 getpmsg, putpmsg 在內(nèi)的好幾個系統(tǒng)調(diào)用都是不進(jìn)行任何操作的，即有待擴(kuò)充的空調(diào)用； 但它們卻仍然占用著sys_call_table表項，估計這是設(shè)計者們?yōu)榱朔奖銛U(kuò)充系統(tǒng)調(diào)用而安排的; 所以只需增加相應(yīng)服務(wù)例程（如增加服務(wù)例程getmsg或putpmsg），就可以達(dá)到增加系統(tǒng)調(diào)用的作用。 結(jié)語：當(dāng)然對于龐大復(fù)雜的 linux 內(nèi)核而言，一篇文章遠(yuǎn)遠(yuǎn)不夠，而且與系統(tǒng)調(diào)用相關(guān)的代碼也只是內(nèi)核中極其微小的一部分；但重要的是方法、掌握好的分析方法；所以上的分析只是起個引導(dǎo)的作用，而正真的分析還有待于讀者自己的努力。 |
|
|
