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/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<linux/unistd.h>
#include<stdio.h>
_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而言,一篇文章遠遠不夠,而且與系統調用相關的代碼也只 是核心中極其微小的一部分,重要的是方法,掌握好的分析方法,所以上述分析只是起個引導作用,而真正的分析還有待讀者自己的努力。