发信人: xiaomiao@GZ()
整理人: qiaoqian(2001-12-31 00:09:15), 站内信件
|
标 题: Linux 内核解读入门
发信站: 网易虚拟社区 (Sat Aug 26 09:55:21 2000), 站内信件
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 的内核源码实在是太大
而且非常
复杂，即便采用了很合理的文件组织方法，在不同目录下的文件之间还是有很多
的关联，
分析核心的一部分代码通常要查看其他的几个相关的文件，而且可能这些文件还
不在同一
个子目录下。
体系的庞大复杂和文件之间关联的错综复杂，可能就是很多人对其望而生畏的主
要原因。
当然，这种令人生畏的劳动所带来的回报也是非常令人着迷的：你不仅可以从中
学到很多
的计算机的底层的知识（如下面将讲到的系统的引导），体会到整个操作系统体
系结构的精
妙和在解决某个具体细节问题时算法的巧妙，而且更重要的是在源码的分析过程
中，你就
会被一点一点地、潜移默化地专业化；甚至，只要分析1/10的代码后，你就会深
刻地体会
到，什么样的代码才是一个专业的程序员写的，什么样的代码是一个业余爱好者
写的。
为了使读者能更好的体会到这一特点，下面举了一个具体的内核分析实例，希望
能通过这
个实例，使读者对 Linux 的内核组织有些具体的认识，读者从中也可以学到一些
对内核的
分析方法。
以下即为分析实例：
（1）操作平台
硬件：cpu intel Pentium II ;
软件：Redhat Linux 6.0; 内核版本2.2.5
（2）相关内核源代码分析
① 系统的引导和初始化：Linux 系统的引导有好几种方式，常见的有 Lilo、Lo
adin引导
和Linux的自举引导（bootsect-loader）,而后者所对应源程序为arch/i386/boo
t/bootsect.S，
它为实模式的汇编程序，限于篇幅在此不做分析。无论是哪种引导方式，最后都
要跳转到
arch/i386/Kernel/setup.S。 setup.S主要是进行时模式下的初始化，为系统进
入保护模式做
准备。此后，系统执行 arch/i386/kernel/head.S (对经压缩后存放的内核要先
执行
arch/i386/boot/compressed/head.S)； head.S 中定义的一段汇编程序setup_i
dt ，它负责建立
一张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_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_table 表定义在
/usr/src/linux/arch/i386/kernel/entry.S 中， 同时在 /usr/src/linux/inc
lude/asm-386/unistd.h 中
也定义了系统调用的用户编程接口。
④ 由此可见 ,Linux 的系统调用也像 dos 系统的 int 21h 中断服务, 它把0x8
0 中断作为
总的入口, 然后转到保存在 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两个。
Linux 内核解读入门(下)
(07/26/2000)
（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而言，一篇文章远远不够，而且与系统调用相关的代
码也只是
内核中极其微小的一部分,重要的是方法,掌握好的分析方法，所以上述分析只是
起个引导作
用，而真正的分析还有待读者自己的努力。
--
/*********************************************
低调，唯美，内省，黑色，简约，折衷，颓废，梦呓，
糜烂，迷乱，阴郁，婉约，低吟，根源，氛围，元素，
极端，低迷，扭曲，爆裂，失落，充斥，具象，聆听，
压抑，气息，炼狱，冰冷，理念，郁闷，神伤，实验，
回归，迷幻，迷离，内敛，艰涩，严肃，模糊，前卫。
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.103.85.54]
|
|