Linux內(nèi)核詳細介紹
Linux內(nèi)核詳細介紹
現(xiàn)如今，電腦的使用越來越普遍，幾乎每家每戶都有電腦，而電腦的操作離不開操作系統(tǒng)，在這里，學習啦小編就向大家介紹Linux內(nèi)核。
很多Linux 愛好者對內(nèi)核很感興趣卻無從下手，本文旨在介紹一種解讀Linux內(nèi)核源碼的入門方法，而不是講解Linux復雜的內(nèi)核機制。
1.核心源程序的文件組織
(1)Linux核心源程序通常都安裝在/usr/src/Linux下，而且它有一個非常簡單的編號約定：任何偶數(shù)的核心(中間數(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)進行組織，在源程序樹的最上層你會看到這樣一些目錄：
arch：arch子目錄包括了所有和體系結(jié)構(gòu)相關(guān)的核心代碼。它的每一個子目錄都代表一種支持的體系結(jié)構(gòu)，例如i386就是關(guān)于Intel CPU及與之相兼容體系結(jié)構(gòu)的子目錄。PC機一般都基于此目錄;
include：include子目錄包括編譯核心所需要的大部分頭文件。與平臺無關(guān)的頭文件在include/linux子目錄下，與Intel CPU相關(guān)的頭文件在include/asm-i386子目錄下，而include/scsi目錄則是有關(guān)SCSI設備的頭文件目錄;
init：這個目錄包含核心的初始化代碼(注：不是系統(tǒng)的引導代碼)，包含兩個文件main.c和Version.c，這是研究核心如何工作的一個非常好的起點;
Mm：這個目錄包括所有獨立于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ù)，其中最重要的文件當屬sched.c，同樣，和體系結(jié)構(gòu)相關(guān)的代碼在arch/*/kernel中;
Drivers：放置系統(tǒng)所有的設備驅(qū)動程序;每種驅(qū)動程序又各占用一個子目錄，如/block下為塊設備驅(qū)動程序，比如ide(ide.c)。如果你希望查看所有可能包含文件系統(tǒng)的設備是如何初始化的，你可以看drivers/block/genhd.c中的device_setup()函數(shù)。它不僅初始化硬盤，也初始化網(wǎng)絡，因為安裝nfs文件系統(tǒng)的時候需要使用網(wǎng)絡。
其他目錄如Lib：放置核心的庫代碼;Net：核心與網(wǎng)絡相關(guān)的代碼;Ipc：包含核心的進程間通信的代碼;Fs：所有的文件系統(tǒng)代碼和各種類型的文件操作代碼，它的每一個子目錄支持一個文件系統(tǒng)，例如fat和ext2、Scripts，此目錄包含用于配置核心的腳本文件等。
一般在每個目錄下都有一個.depend 文件和一個Makefile 文件，這兩個文件都是編譯時使用的輔助文件，仔細閱讀這兩個文件對弄清各個文件之間的聯(lián)系和依托關(guān)系很有幫助，而且在有的目錄下還有Readme 文件，它是對該目錄下的文件的一些說明，同樣有利于我們對內(nèi)核源碼的理解。
2.解讀實戰(zhàn)：為你的內(nèi)核增加一個系統(tǒng)調(diào)用
雖然Linux 的內(nèi)核源碼用樹形結(jié)構(gòu)組織得非常合理、科學，把與功能相關(guān)聯(lián)的文件都放在同一個子目錄下，這樣使得程序更具可讀性。然而，Linux 的內(nèi)核源碼實在是太大而且非常復雜，即便采用了很合理的文件組織方法，在不同目錄下的文件之間還是有很多的關(guān)聯(lián)，分析核心的一部分代碼通常要查看其他的幾個相關(guān)的文件，而且可能這些文件還不在同一個子目錄下。
下面舉一個具體的內(nèi)核分析實例，希望能通過這個實例，使讀者對Linux 的內(nèi)核組織有些具體的認識，讀者從中也可以學到一些對內(nèi)核的分析方法。
以下即為分析實例：
(1)操作平臺
硬件：CPU Intel Pentium II;
軟件：Redhat Linux 6.0，內(nèi)核版本2.2.5
(2)相關(guān)內(nèi)核源代碼分析
?、傧到y(tǒng)的引導和初始化：Linux 系統(tǒng)的引導有好幾種方式，常見的有Lilo、Loadin引導和Linux的自舉引導(bootsect-loader)，而后者所對應源程序為arch/i386/boot/bootsect.S，它為實模式的匯編程序，限于篇幅在此不做分析。無論是哪種引導方式，最后都要跳轉(zhuǎn)到arch/i386/Kernel/setup.S。setup.S主要是進行實模式下的初始化，為系統(tǒng)進入保護模式做準備。此后，系統(tǒng)執(zhí)行arch/i386/kernel/head.S (對經(jīng)壓縮后存放的內(nèi)核要先執(zhí)行arch/i386/boot/compressed/head.S);head.S 中定義的一段匯編程序setup_idt，它負責建立一張256項的idt表(Interrupt Descriptor Table)，此表保存著所有自陷和中斷的入口地址，其中包括系統(tǒng)調(diào)用總控程序system_call 的入口地址。當然，除此之外，head.S還要做一些其他的初始化工作。
②系統(tǒng)初始化后運行的第一個內(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) 把各個自陷和中斷服務程序的入口地址設置到idt表中，其中系統(tǒng)調(diào)用總控程序system_cal就是中斷服務程序之一;void __init trap_init(void)函數(shù)則通過調(diào)用一個宏set_system_gate(SYSCALL_VECTOR，&system_call)，把系統(tǒng)調(diào)用總控程序的入口掛在中斷0x80上。
其中SYSCALL_VECTR是定義在/usr/src/linux/arch/i386/kernel/irq.h中的一個常量0x80，而system_call 即為中斷總控程序的入口地址，中斷總控程序用匯編語言定義在/usr/src/linux/arch/i386/kernel/entry.S中。
?、壑袛嗫偪爻绦蛑饕撠煴４嫣幚頇C執(zhí)行系統(tǒng)調(diào)用前的狀態(tài)，檢驗當前調(diào)用是否合法，并根據(jù)系統(tǒng)調(diào)用向量，使處理機跳轉(zhuǎn)到保存在sys_call_table 表中的相應系統(tǒng)服務例程的入口，從系統(tǒng)服務例程返回后恢復處理機狀態(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)用的用戶編程接口。
?、苡纱丝梢姡琇inux的系統(tǒng)調(diào)用也像DOS系統(tǒng)的int 21h中斷服務，大把0x80中斷作為總的入口，然后轉(zhuǎn)到保存在sys_call_table表中的各種中斷服務例程的入口地址，提供各種不同的中斷服務。
提供上源代碼分析可知，要增加一個系統(tǒng)調(diào)用就必須在sys_call_table表中增加一項，并在其中保存好自己的系統(tǒng)服務例程的入口地址，然后重新編譯內(nèi)核，當然，系統(tǒng)服務例程是必不可少的。
由此可知，在此版Linux內(nèi)核源程序<2.2.5>中，與系統(tǒng)調(diào)用相關(guān)的源程序文件就包括以下這些：
* 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
當然，這只是涉及到的幾個主要文件。而事實上，增加系統(tǒng)調(diào)用真正要修改的文件只有include/asm-386/unistd.h 和arch/i386/kernel/entry.S兩個。
(3)源碼的修改
?、賙ernel/sys.c中增加系統(tǒng)服務例程如下：
asmlinkage int sys_addtotal(int numdata)
{ int i=0，enddata=0;
while(i<=numdata)
enddata+=i++;
return enddata; }
該函數(shù)有一個int 型入口參數(shù)numdata ， 并返回從0 到numdata 的累加值，然而也可以把系統(tǒng)服務例程放在一個自己定義的文件或其他文件中，只是要在相應文件中作必要的說明。
②把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 中進行必要申明，以供用戶進程和其他系統(tǒng)進程查詢或調(diào)用。
增加后的部分/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
?、軠y試程序(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); }
對修改后的新的內(nèi)核進行編譯，并引導它作為新的操作系統(tǒng)，運行幾個程序后可以發(fā)現(xiàn)一切正常;在新的系統(tǒng)下對測試程序進行編譯(注：由于原內(nèi)核并未提供此系統(tǒng)調(diào)用，所以只有在編譯后的新內(nèi)核下，此測試程序才可能被編譯通過)，運行情況如下：
$gcc .test test.c
$./test
Please input a number
36
Total from 0 to 36 is 666
修改成功后對相關(guān)源碼進一步分析可知，在此版本的內(nèi)核中，從/usr/src/linux/arch/i386/kernel/entry.S 文件中對sys_call_table 表的設置可以看出，有好幾個系統(tǒng)調(diào)用的服務例程都是定義在/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ù)并不進行任何操作，所以包括getpmsg， putpmsg 在內(nèi)的好幾個系統(tǒng)調(diào)用都是不進行任何操作的，即有待擴充的空調(diào)用;但它們卻仍然占用著sys_call_table表項，估計這是設計者們?yōu)榱朔奖銛U充系統(tǒng)調(diào)用而安排的，所以只需增加相應服務例程(如增加服務例程getmsg或putpmsg)，就可以達到增加系統(tǒng)調(diào)用的作用。
3.結(jié)束語
要完全解讀龐大復雜的Linux內(nèi)核，一篇文章遠遠不能介紹清楚，而且與系統(tǒng)調(diào)用相關(guān)的代碼也只是內(nèi)核中極其微小的一部分，重要的是方法，掌握好的分析方法，所以上述分析只是起個引導作用，而真正的分析還有待讀者自己的努力。