Linux 内核解读入门
一.核心源程序的文件组织: 1.Linux核心源程序通常都安装在/usr/src/linux下,而且它有一个非常简单的编号约定:任何偶数的核心(例如2.0.30)都是一个稳定地发行的核心,而任何奇数的核心(例如2.1.42)都是一个开发中的核心。
2.核心源程序的文件按树形结构进行组织,在源程序树的最上层你会看到这样一些目录: ●Arch :arch子目录包括了所有和体系结构相关的核心代码。它的每一个子目录都代表一种支持的体系结构,例如i386就是关于intel ●Include: include子目录包括编译核心所需要的大部分头文件。与平台无关的头文件在 include/linux子目录下,与 intel ●Init: 这个目录包含核心的初始化代码(注:不是系统的引导代码),包含两个文件main.c和Version.c,这是研究核心如何工作的一个非常好的起点。 ●Mm :这个目录包括所有独立于 cpu
Scripts, 此目录包含用于配置核心的脚本文件等。 一般,在每个目录下,都有一个 .depend 文件和一个 Makefile
虽然,Linux 的内核源码用树形结构组织得非常合理、科学,把功能相关联的文件都放在同一个子目录下,这样使得程序更具可读性。然而,Linux
以下即为分析实例: 【一】操作平台: 硬件:cpu intel Pentium II ; 软件:Redhat Linux 6.0; 内核版本2.2.5【二】相关内核源代码分析: 1.系统的引导和初始化:Linux 系统的引导有好几种方式:常见的有 Lilo, 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 set_system_gate(SYSCALL_VECTOR,&system_call); 把系统调用总控程序的入口挂在中断0x80上; 其中SYSCALL_VECTOR是定义在 /usr/src/linux/arch/i386/kernel/irq.h中的一个常量0x80; 而 3.中断总控程序主要负责保存处理机执行系统调用前的状态,检验当前调用是否合法, 并根据系统调用向量,使处理机跳转到保存在 sys_call_table 而系统调用向量则定义在/usr/src/linux/include/asm-386/unistd.h 中;sys_call_table 4.由此可见 , linux 的系统调用也象 dos 系统的 int 21h 中断服务, 它把0x80 中断作为总的入口, 然后转到保存在 由以上源代码分析可知, 要增加一个系统调用就必须在 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;
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); } 对修改后的新的内核进行编译,并引导它作为新的操作系统,运行几个程序后可以发现一切正常;在新的系统下对测试程序进行编译(*注:由于原内核并未提供此系统调用,所以只有在编译后的新内核下,此测试程序才能可能被编译通过),运行情况如下:
$./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, 结语:当然对于庞大复杂的 linux ----摘自“安盟” |
Linux 内核解读入门
最新推荐文章于 2024-03-30 14:02:26 发布