Linux内核源码目录

Posted 2022-12-11 絮雨清风

                                                                                                                                来源：http://blog.chinaunix.net/uid-23860671-id-152897.html

一、代码目录结构

        在阅读源码之前，还应知道Linux内核源码的整体分布情况。现代的操作系统一般由进程管理、内存管理、文件系统、驱动程序和网络等组成。Linux内核源码的各个目录大致与此相对应，其组成如下（假设相对于Linux-2.4.23目录）：

        arch目录包括了所有和体系结构相关的核心代码。它下面的每一个子目录都代表一种Linux支持的体系结构，例如i386就是Intel CPU及与之相兼容体系结构的子目录。PC机一般都基于此目录。

        include目录包括编译核心所需要的大部分头文件，例如与平台无关的头文件在include/linux子目录下。

        init目录包含核心的初始化代码（不是系统的引导代码），有main.c和Version.c两个文件。这是研究核心如何工作的好起点。

        mm目录包含了所有的内存管理代码。与具体硬件体系结构相关的内存管理代码位于arch/*/mm目录下。

        drivers目录中是系统中所有的设备驱动程序。它又进一步划分成几类设备驱动，每一种有对应的子目录，如声卡的驱动对应于drivers/sound。

        ipc目录包含了核心进程间的通信代码。

        modules目录存放了已建好的、可动态加载的模块。

        fs目录存放Linux支持的文件系统代码。不同的文件系统有不同的子目录对应，如ext3文件系统对应的就是ext3子目录。

        Kernel内核管理的核心代码放在这里。同时与处理器结构相关代码都放在arch/*/kernel目录下。

        net目录里是核心的网络部分代码，其每个子目录对应于网络的一个方面。

        lib目录包含了核心的库代码，不过与处理器结构相关的库代码被放在arch/*/lib/目录下。

        scripts目录包含用于配置核心的脚本文件。

        documentation目录下是一些文档，是对每个目录作用的具体说明。

     一般在每个目录下都有一个.depend文件和一个Makefile文件。这两个文件都是编译时使用的辅助文件。仔细阅读这两个文件对弄清各个文件之间的联系和依托关系很有帮助。另外有的目录下还有Readme文件，它是对该目录下文件的一些说明，同样有利于对内核源码的理解。

二、相关内核源代码分析： 

       

        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内核源程序<2.2.5>中,与系统调用相关的源程序文件就包括以下这些：

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 内核而言，一篇文章远远不够，而且与系统调用相关的代码也只是内核中极其微小的一部分；但重要的是方法、掌握好的分析方法；所以上的分析只是起个引导的作用，而正真的分析还有待于读者自己的努力。