《解读linux内核源码入门》由会员分享，可在线阅读，更多相关《解读linux内核源码入门（7页珍藏版）》请在金锄头文库上搜索。
1、一核心源程序的文件组织： 1Linux 核心源程序通常都安装在/usr/src/linux 下，而且它有一个非常简单的编号 约定：任何偶数的核心（例如 2.0.30）都是一个稳定地发行的核心，而任何奇数的核心 （例如 2.1.42）都是一个开发中的核心。 本文基于稳定的 2.2.5 源代码，第二部分的实现平台为 Redhat Linux 6.0。 2核心源程序的文件按树形结构进行组织，在源程序树的最上层你会看到这样一些目 录： Arch ：arch 子目录包括了所有和体系结构相关的核心代码。它的每一个子目录都代 表一种支持的体系结构，例如 i386 就是关于 intel cpu 及与之相兼容体
2、系结构的子目录。 PC 机一般都基于此目录； Include: include 子目录包括编译核心所需要的大部分头文件。与平台无关的头文 件在 include/linux 子目录下，与 intel cpu 相关的头文件在 include/asm-i386 子目录下,而 include/scsi 目录则是有关 scsi 设备的头文件目录； Init： 这个目录包含核心的初始化代码(注：不是系统的引导代码)，包含两个文件 main.c 和 Version.c，这是研究核心如何工作的一个非常好的起点。 Mm ：这个目录包括所有独立于 cpu 体系结构的内存管理代码，如页式存储管理内存 的分配和释放等
3、；而和体系结构相关的内存管理代码则位于 arch/*/mm/，例如arch/i386/mm/Fault.c Kernel：主要的核心代码，此目录下的文件实现了大多数 linux 系统的内核函数，其 中最重要的文件当属 sched.c；同样，和体系结构相关的代码在 arch/*/kernel 中； Drivers： 放置系统所有的设备驱动程序;每种驱动程序又各占用一个子目录：如，/block 下为块设备驱动程序，比如 ide（ide.c） 。如果你希望查看所有可能包含文件系统的设 备是如何初始化的，你可以看 drivers/block/genhd.c 中的 device_setup()。它不仅初
4、始 化硬盘，也初始化网络，因为安装 nfs 文件系统的时候需要网络其他: 如, Lib 放置核心的库代码; Net,核心与网络相关的代码; Ipc,这个目录包含核心的进 程间通讯的代码; Fs ,所有的文件系统代码和各种类型的文件操作代码，它的每一个子目录 支持一个文件系统，例如 fat 和 ext2; Scripts, 此目录包含用于配置核心的脚本文件等。 一般，在每个目录下，都有一个 .depend 文件和一个 Makefile 文件，这两个文件都 是编译时使用的辅助文件，仔细阅读这两个文件对弄清各个文件这间的联系和依托关系很有 帮助；而且，在有的目录下还有 Readme 文件，它是对该目
5、录下的文件的一些说明，同样有利于我们对内核源码的理解； 二解读实战：为你的内核增加一个系统调用 虽然，Linux 的内核源码用树形结构组织得非常合理、科学，把功能相关联的文件都放 在同一个子目录下，这样使得程序更具可读性。然而，Linux 的内核源码实在是太大而且非 常复杂，即便采用了很合理的文件组织方法，在不同目录下的文件之间还是有很多的关联， 分析核心的一部分代码通常会要查看其它的几个相关的文件，而且可能这些文件还不在同一 个子目录下。 体系的庞大复杂和文件之间关联的错综复杂，可能就是很多人对其望而生畏的主要原因。 当然，这种令人生畏的劳动所带来的回报也是非常令人着迷的：你不仅可以从中学到
6、很多的 计算机的底层的知识（如下面将讲到的系统的引导） ，体会到整个操作系统体系结构的精妙 和在解决某个具体细节问题时，算法的巧妙；而且更重要的是：在源码的分析过程中，你就 会被一点一点地、潜移默化地专业化；甚至，只要分析十分之一的代码后，你就会深刻地体 会到，什么样的代码才是一个专业的程序员写的，什么样的代码是一个业余爱好者写的。 为了使读者能更好的体会到这一特点，下面举了一个具体的内核分析实例，希望能通过 这个实例，使读者对 Linux 的内核的组织有些具体的认识，从中读者也可以学到一些对内核的分析方法。 以下即为分析实例： 【一】操作平台: 硬件：cpu intel Pentium II
7、 ; 软件：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
8、(对经 压缩后存放的内核要先执行 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
9、 中,它通过调用 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, 把系统调用总控程序的入口挂在中断 0x80 上; 其中 SYSCALL_VECTOR 是定义在 /usr/src/linux/arch/i386/kernel/irq.h 中的
10、一 个常量 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/li
11、nux/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 表中增加一项 , 并在其中保存好自己的系统服务例程的入口地址,然后重 新编译内核，当然，系统
12、服务例程是必不可少的。 由此可知在此版 linux 内核源程序中,与系统调用相关的源程序文件就包括以下这些: 1arch/i386/boot/bootsect.S 2arch/i386/Kernel/setup.S 3arch/i386/boot/compressed/head.S 4arch/i386/kernel/head.S 5init/main.c 6arch/i386/kernel/traps.c 7arch/i386/kernel/entry.S 8arch/i386/kernel/irq.h 9include/asm-386/unistd.h 当然，这只是涉及到的几个主要文件。而
13、事实上，增加系统调用真正要修改文件只有 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 的累加值; 当然也可以把系统服务例程放在一个自己定义的文件或其
14、他文件中，只是要在相应文件 中作必要的说明； 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 */
15、 .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_sy
16、scalls-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 numb
