Linux內核解讀入門

很多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/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 文件，它是對該目錄下的文件的一些說明，同樣有利於我們對內核源碼的理解。
　　2．解讀實戰：為你的內核增加一個系統調用
　　雖然Linux 的內核源碼用樹形結構組織得非常合理、科學，把與功能相關聯的文件都放在同一個子目錄下，這樣使得程序更具可讀性。然而，Linux 的內核源碼實在是太大而且非常複雜，即便採用了很合理的文件組織方法，在不同目錄下的文件之間還是有很多的關聯，分析核心的一部分代碼通常要查看其他的幾個相關的文件，而且可能這些文件還不在同一個子目錄下。
　　下面舉一個具體的內核分析實例，希望能通過這個實例，使讀者對Linux 的內核組織有些具體的認識，讀者從中也可以學到一些對內核的分析方法。
　　以下即為分析實例：
　　（1）操作平台
　　硬體：CPU Intel Pentium II；
　　軟體：Redhat Linux 6.0，內核版本2.2.5
　　（2）相關內核源代碼分析
　　①系統的引導和初始化：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還要做一些其他的初始化工作。
　　②系統初始化后運行的第一個內核程序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_VECTR是定義在/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_table 表定義在/usr/src/linux/arch/i386/kernel/entry.S 中，同時在/usr/src/linux/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
　　＊ rch/i386/Kernel/setup.S
　　＊ rch/i386/boot/compressed/head.S
　　＊ rch/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 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 .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內核，一篇文章遠遠不能介紹清楚，而且與系統調用相關的代碼也只是內核中極其微小的一部分，重要的是方法，掌握好的分析方法，所以上述分析只是起個引導作用，而真正的分析還有待讀者自己的努力

Tags: linux system 內核