|
|
--------------------------------------------------------------------------------
虽然，Linux
的内核源码用树形结构组织得非常合理、科学，把功能相关联的文件都放在同一个子目录下，这样使得程序更具可读性。然而，Linux
的内核源码实在是太大而且非常复杂，即便采用了很合理的文件组织方法，在不同目录下的文件之间还是有很多的关联，分析核心的一部分代码通常会要查看其它的几个相关的文件，而且可能这些文件还不在同一个子目录下。
体系的庞大复杂和文件之间关联的错综复杂，可能就是很多人对其望而生畏的主要原因。当然，这种令人生畏的劳动所带来的回报也是非常令人着迷的：你不仅可以从中学到很多的计算机的底层的知识（如下面将讲到的系统的引导），体会到整个操作系统体系结构的精妙和在解决某个具体细节问题时，算法的巧妙；而且更重要的是：在源码的分析过程中，你就会被一点一点地、潜移默化地专业化；甚至，只要分析十分之一的代码后，你就会深刻地体会到，什么样的代码才是一个专业的程序员写的，什么样的代码是一个业余爱好者写的。
为了使读者能更好的体会到这一特点，下面举了一个具体的内核分析实例，希望能通过这个实例，使读者对
Linux的内核的组织有些具体的认识，从中读者也可以学到一些对内核的分析方法。
以下即为分析实例：
【一】操作平台:
硬件：cpu intel Pentium II ;
软件：Redhat Linux 6.0;
内核版本2.2.5【二】相关内核源代码分析:
1．系统的引导和初始化：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还要做一些其他的初始化工作；
2．系统初始化后运行的第一个内核程序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中;
3.中断总控程序主要负责保存处理机执行系统调用前的状态,检验当前调用是否合法,
并根据系统调用向量，使处理机跳转到保存在
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
中也定义了系统调用的用户编程接口;
4.由此可见 , linux 的系统调用也象 dos 系统的 int 21h
中断服务, 它把0x80 中断作为总的入口,
然后转到保存在 sys_call_table
表中的各种中断服务例程的入口地址 ,
形成各种不同的中断服务;
由以上源代码分析可知, 要增加一个系统调用就必须在
sys_call_table 表中增加一项 ,
并在其中保存好自己的系统服务例程的入口地址,然后重新编译内核，当然，系统服务例程是必不可少的。
由此可知在此版linux内核源程序中,与系统调用相关的源程序文件就包括以下这些:
1．arch/i386/boot/bootsect.S
2．arch/i386/Kernel/setup.S
3．arch/i386/boot/compressed/head.S
4．arch/i386/kernel/head.S
5．init/main.c
6．arch/i386/kernel/traps.c
7．arch/i386/kernel/entry.S
8．arch/i386/kernel/irq.h
9．include/asm-386/unistd.h
当然，这只是涉及到的几个主要文件。而事实上，增加系统调用真正要修改文件只有include/asm-386/unistd.h和arch/i386/kernel/entry.S两个;
【三】 对内核源码的修改：
1.在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 的累加值;
当然也可以把系统服务例程放在一个自己定义的文件或其他文件中，只是要在相应文件中作必要的说明；
2.把 asmlinkage 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
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 number\n");
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
内核而言，一篇文章远远不够，而且与系统调用相关的代码也只是内核中极其微小的一部分；但重要的是方法、掌握好的分析方法；所以上的分析只是起个引导的作用，而正真的分析还有待于读者自己的努力。
--
耳朵说
如果有来世，让我们做一对小小的老鼠，笨笨地相爱，呆呆地过日子，拙拙地相恋，傻傻地在一起，即使大雪封山，还可以窝在暖暖的草堆，紧紧地抱着你，轻轻地咬你的耳朵，悄悄地告诉你：我爱你…… |
|
IP卡
狗仔卡
发表于 2006-6-3 00:44:22
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡