linux内核在什么目录结构,Linux Kernel 目录结构说明

核心源程序的文件按树形结构进行组织，在源程序树的最上层你会看到这样一些目录：

· Arch ：包括了所有和体系结构相关的核心代码。它的每一个子目录都代表一种支持的体系结构，例如i386就是关于intel cpu及与之相兼容体系结构的子目录。PC机一般都基于此目录；

· 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 (for building)

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