針對好多Linux 愛好者對內核很有興趣卻無從下口，本文旨在介紹一種解讀linux內核源碼的入門方法，而不是解說linux復雜的內核機制；
一．核心源程序的文件組織：
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 文件，它是對該目錄下的文件的一些說明，同樣有利於我們對內核源碼的理解；
3. 把增加的 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
4.測試程序(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 -o 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），就可以達到增加系統調用的作用。
結語：當然對於龐大復雜的 linux 內核而言，一篇文章遠遠不夠，而且與系統調用相關的代碼也只是內核中極其微小的一部分；但重要的是方法、掌握好的分析方法；所以上的分析只是起個引導的作用，而正真的分析還有待於讀者自己的努力。:)
