PHPor 的Blog

用户空间工具：

    
• 内存工具：MEMWATCH 和 YAMD

    

• strace

    

• GNU 调试器（gdb）

    

• 魔术键控顺序

C 语言作为 Linux 系统上标准的编程语言给予了我们对动态内存分配很大的控制权。然而，这种自由可能会导致严重的内存管理问题，而这些问题可能导致程序崩溃或随时间的推移导致性能降级。

内存泄漏（即 malloc() 内存在对应的 free() 调用执行后永不被释放）和缓冲区溢出（例如对以前分配到某数组的内存进行写操作）是一些常见的问题，它们可能很难检测到。这一部分将讨论几个调试工具，它们极大地简化了检测和找出内存问题的过程。

MEMWATCH 由 Johan Lindh 编写，是一个开放源代码 C 语言内存错误检测工具，您可以自己下载它（请参阅本文后面部分的参考资料）。只要在代码中添加一个头文件并在 gcc 语句中定义了 MEMWATCH 之后，您就可以跟踪程序中的内存泄漏和错误了。MEMWATCH 支持 ANSI C，它提供结果日志纪录，能检测双重释放（double-free）、错误释放（erroneous free）、没有释放的内存（unfreed memory）、溢出和下溢等等。

    
• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
      
      

    

• 下载 MEMWATCH。
      
      
      
      

    

• 请查看 Dynamic Probes 调试功能程序。
      
      
      
      

    

• 请阅读文章“ Linux software debugging with GDB”。（ developerWorks，2001 年 2 月）
      
      
      
      

    

• 请访问 IBM Linux Technology Center。
      
      
      
      

    

• 在 developerWorksLinux 专区可以找到 更多的 Linux 文章。

原文地址：http://www-128.ibm.com/developerworks/cn/linux/sdk/l-debug/index.html

    
• Linux下系统调用的实现

    
1. Unix/Linux操作系统的体系结构及系统调用介绍

    
        
1. 什么是操作系统和系统调用         

               操作系统是从硬件抽象出来的虚拟机，在该虚拟机上用户可以运行应用程序。它负责直接与硬件交互，向用户程序提供公共服务，并使它们同硬件特性隔离。因为程序不应该依赖于下层的硬件，只有这样应用程序才能很方便的在各种不同的Unix系统之间移动。系统调用是Unix/Linux操作系统向用户程序提供支持的接口，通过这些接口应用程序向操作系统请求服务，控制转向操作系统，而操作系统在完成服务后，将控制和结果返回给用户程序。
           　

           

        

2. Unix/Linux系统体系结构        

           一个Unix/Linux系统分为三个层次：用户、核心以及硬件。
           
           　    其中系统调用是用户程序与核心间的边界，通过系统调用进程可由用户模式转入核心模式，在核心模式下完成一定的服务请求后在返回用户模式。

           

       系统调用接口看起来和C程序中的普通函数调用很相似，它们通常是通过库把这些函数调用映射成进入操作系统所需要的原语。

           

       这些操作原语只是提供一个基本功能集，而通过库对这些操作的引用和封装，可以形成丰富而且强大的系统调用库。这里体现了机制与策略相分离的编程思想——系统调用只是提供访问核心的基本机制，而策略是通过系统调用库来体现。

           

   例：execv, execl, execlv, opendir , readdir…

           

   　

           

        

3. Unix/Linux运行模式，地址空间和上下文
                    

    

           

   运行模式（运行态）：

           

       一种计算机硬件要运行Unix/Linux系统，至少需要提供两种运行模式：高优先级的核心模式和低优先级的用户模式。

           

       实际上许多计算机都有两种以上的执行模式。如：intel 80×86体系结构就有四层执行特权，内层特权最高。Unix只需要两层即可以了：核心运行在高优先级，称之为核心态；其它外围软件包括shell，编辑程序，Xwindow等等都是在低优先级运行，称之为用户态。之所以采取不同的执行模式主要原因时为了保护，由于用户进程在较低的特权级上运行，它们将不能意外或故意的破坏其它进程或内核。程序造成的破坏会被局部化而不影响系统中其它活动或者进程。当用户进程需要完成特权模式下才能完成的某些功能时，必须严格按照系统调用提供接口才能进入特权模式，然后执行调用所提供的有限功能。

           

       每种运行态都应该有自己的堆栈。在Linux中，分为用户栈和核心栈。用户栈包括在用户态执行时函数调用的参数、局部变量和其它数据结构。有些系统中专门为全局中断处理提供了中断栈，但是x86中并没有中断栈，中断在当前进程的核心栈中处理。

           

   地址空间：

           

       采用特权模式进行保护的根本目的是对地址空间的保护，用户进程不应该能够访问所有的地址空间：只有通过系统调用这种受严格限制的接口，进程才能进入核心态并访问到受保护的那一部分地址空间的数据，这一部分通常是留给操作系统使用。另外，进程与进程之间的地址空间也不应该随便互访。这样，就需要提供一种机制来在一片物理内存上实现同一进程不同地址空间上的保护，以及不同进程之间地址空间的保护。

           

       Unix/Linux中通过虚存管理机制很好的实现了这种保护，在虚存系统中，进程所使用的地址不直接对应物理的存储单元。每个进程都有自己的虚存空间，每个进程有自己的虚拟地址空间，对虚拟地址的引用通过地址转换机制转换成为物理地址的引用。正因为所有进程共享物理内存资源，所以必须通过一定的方法来保护这种共享资源，通过虚存系统很好的实现了这种保护：每个进程的地址空间通过地址转换机制映射到不同的物理存储页面上，这样就保证了进程只能访问自己的地址空间所对应的页面而不能访问或修改其它进程的地址空间对应的页面。

           

       虚拟地址空间分为两个部分：用户空间和系统空间。在用户模式下只能访问用户空间而在核心模式下可以访问系统空间和用户空间。系统空间在每个进程的虚拟地址空间中都是固定的，而且由于系统中只有一个内核实例在运行，因此所有进程都映射到单一内核地址空间。内核中维护全局数据结构和每个进程的一些对象信息，后者包括的信息使得内核可以访问任何进程的地址空间。通过地址转换机制进程可以直接访问当前进程的地址空间（通过MMU），而通过一些特殊的方法也可以访问到其它进程的地址空间。

           

       尽管所有进程都共享内核，但是系统空间是受保护的，进程在用户态无法访问。进程如果需要访问内核，则必须通过系统调用接口。进程调用一个系统调用时，通过执行一组特殊的指令（这个指令是与平台相关的，每种系统都提供了专门的trap命令，基于x86的Linux中是使用int 指令）使系统进入内核态，并将控制权交给内核，由内核替代进程完成操作。当系统调用完成后，内核执行另一组特征指令将系统返回到用户态，控制权返回给进程。

           

   上下文：

           

       一个进程的上下文可以分为三个部分：用户级上下文、寄存器上下文以及系统级上下文。

           

       用户级上下文：正文、数据、用户栈以及共享存储区；

           

       寄存器上下文：程序寄存器（IP），即CPU将执行的下条指令地址，处理机状态寄存器（EFLAGS），栈指针，通用寄存器；

           

       系统级上下文：进程表项(proc结构)和U区，在Linux中这两个部分被合成task_struct，区表及页表(mm_struct , vm_area_struct, pgd, pmd, pte等)，核心栈等。

           

       全部的上下文信息组成了一个进程的运行环境。当发生进程调度时，必须对全部上下文信息进行切换，新调度的进程才能运行。进程就是上下文的集合的一个抽象概念。

           

   　

           

        

4. 系统调用的功能和分类

    

    
        ( setup_idt:        

lea ignore_int,%edx

        

movl $(__KERNEL_CS << 16),%eax

        

movw %dx,%ax /* selector = 0x0010 = cs */

        

movw $0x8E00,%dx /* interrupt gate – dpl=0, present */

        

lea SYMBOL_NAME(idt_table),%edi

        

mov $256,%ecx

        

rp_sidt:

        

movl %eax,(%edi)

        

movl %edx,4(%edi)

        

addl $8,%edi

        

dec %ecx

        

jne rp_sidt

        

ret

        

selector = __KERNEL_CS, DPL = 0, TYPE = E, P = 1）;

        

2.Start_kernel()(linux/init/main.c)调用trap_init()(linux/arch/i386/kernel/trap.c)函数设置中断描述符表。在该函数里，实际上是通过调用函数set_system_gate(SYSCALL_VECTOR,&system_call)来完成该项的设置的。其中的SYSCALL_VECTOR就是0x80，而system_call则是一个汇编子函数，它即是中断0x80的处理函数，主要完成两项工作：a. 寄存器上下文的保存；b. 跳转到系统调用处理函数。在后面会详细介绍这些内容。

    

    
B.与系统调用相关的数据结构        

1.系统调用处理函数的函数名的约定

        

    函数名都以“sys_”开头，后面跟该系统调用的名字。例如，系统调用fork()的处理函数名是sys_fork()。

        

asmlinkage int sys_fork(struct pt_regs regs);

        

（补充关于asmlinkage的说明）

        

　
        2.系统调用号（System Call Number）

        

    核心中为每个系统调用定义了一个唯一的编号，这个编号的定义在linux/include/asm/unistd.h中，编号的定义方式如下所示：

        

#define __NR_exit 1

        

#define __NR_fork 2

        

#define __NR_read 3

        

#define __NR_write 4

        

. . . . . .

        

    用户在调用一个系统调用时，系统调用号号作为参数传递给中断0x80，而该标号实际上是后面将要提到的系统调用表(sys_call_table)的下标，通过该值可以找到相映系统调用的处理函数地址。

        

　
        3.系统调用表

    

    
            如前面提到的，系统调用是通过一条陷入指令进入核心态，然后根据传给核心的系统调用号为索引在系统调用表中找到相映的处理函数入口地址。这里将详细介绍这一过程。        

    我们还是以x86为例说明：

        

    由于陷入指令是一条特殊指令，而且依赖与操作系统实现的平台，如在x86中，这条指令是int 0x80，这显然不是用户在编程时应该使用的语句，因为这将使得用户程序难于移植。所以在操作系统的上层需要实现一个对应的系统调用库，每个系统调用都在该库中包含了一个入口点（如我们看到的fork, open, close等等），这些函数对程序员是可见的，而这些库函数的工作是以对应系统调用号作为参数，执行陷入指令int 0x80，以陷入核心执行真正的系统调用处理函数。当一个进程调用一个特定的系统调用库的入口点，正如同它调用任何函数一样，对于库函数也要创建一个栈帧。而当进程执行陷入指令时，它将处理机状态转换到核心态，并且在核心栈执行核心代码。

        

    这里给出一个示例（linux/include/asm/unistd.h）：

        

#define _syscallN(type, name, type1, arg1, type2, arg2, . . . ) \

        

type name(type1 arg1,type2 arg2) \

        

{ \

        

long __res; \

        

__asm__ volatile ("int $0x80" \

        

: "=a" (__res) \

        

: "" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2))); \

        

. . . . . .

        

__syscall_return(type,__res); \

        

}

        

    在执行一个系统调用库中定义的系统调用入口函数时，实际执行的是类似如上的一段代码。这里牵涉到一些gcc的嵌入式汇编语言，不做详细的介绍，只简单说明其意义：

        

    其中__NR_##name是系统调用号，如name == ioctl，则为__NR_ioctl，它将被放在寄存器eax中作为参数传递给中断0x80的处理函数。而系统调用的其它参数arg1, arg2, …则依次被放入ebx, ecx, . . .等通用寄存器中，并作为系统调用处理函数的参数，这些参数是怎样传入核心的将会在后面介绍。

        

    下面将示例说明：

        

int func1()

        

{

        

int fd, retval;

        

fd = open(filename, ……);

        

……

        

ioctl(fd, cmd, arg);

        

. . .

        

}

        

　

        

func2()

        

{

        

int fd, retval;

        

fd = open(filename, ……);

        

……

        

__asm__ __volatile__(\

        

"int $0x80\n\t"\

        

:"=a"(retval)\

        

:"0"(__NR_ioctl),\

        

"b"(fd),\

        

"c"(cmd),\

        

"d"(arg));

        

}

        

    这两个函数在Linux/x86上运行的结果应该是一样的。

        

    若干个库函数可以映射到同一个系统调用入口点。系统调用入口点对每个系统调用定义其真正的语法和语义，但库函数通常提供一个更方便的接口。如系统调用exec有集中不同的调用方式：execl, execle,等，它们实际上只是同一系统调用的不同接口而已。对于这些调用，它们的库函数对它们各自的参数加以处理，来实现各自的特点，但是最终都被映射到同一个核心入口点。

        

　D.系统调用陷入内核后作何初始化处理

    

          在这里所做的所有工作是：
           1.保存EAX寄存器，因为在SAVE_ALL中保存的EAX寄存器会被调用的返回值所覆盖；
           2.调用SAVE_ALL保存寄存器上下文；
           3.判断当前调用是否是合法系统调用（EAX是系统调用号，它应该小于NR_syscalls）；
           4.如果设置了PF_TRACESYS标志，则跳转到syscall_trace，在那里将会把当前进程挂起并向其父进程发送SIGTRAP，这主要是为了设              置调试断点而设计的；
           5.如果没有设置PF_TRACESYS标志，则跳转到该系统调用的处理函数入口。这里是以EAX（即前面提到的系统调用号）作为偏移，在系             统调用表sys_call_table中查找处理函数入口地址，并跳转到该入口地址。
　

    
        #define GET_CURRENT(reg)        

movl %esp, reg;

        

andl $-8192, reg;

        

    其作用是取得当前进程的task_struct结构的指针返回到reg中，因为在Linux中核心栈的位置是task_struct之后的两个页面处（8192bytes），所以此处把栈指针与-8192则得到的是task_struct结构指针，而task_struct中偏移为4的位置是成员flags，在这里指令testb $0x20,flags(%ebx)检测的就是task_struct->flags。

        


        2.堆栈中的参数

        

    正如前面提到的，SAVE_ALL是系统调用参数的传入过程，当执行完SAVE_ALL并且再由CALL指令调用其处理函数时，堆栈的结构应该如上图所示。这时的堆栈结构看起来和执行一个普通带参数的函数调用是一样的，参数在堆栈中对应的顺序是（arg1， ebx），（arg2, ecx）,（arg3, edx）. . . . . .，这正是SAVE_ALL压栈的反顺序，这些参数正是用户在使用系统调用时试图传送给核心的参数。下面是在核心的调用处理函数中使用参数的两种典型方法：

        

asmlinkage int sys_fork(struct pt_regs regs)；

        

asmlinkage int sys_open(const char * filename, int flags, int mode)；

        

    在sys_fork中，把整个堆栈中的内容视为一个struct pt_regs类型的参数，该参数的结构和堆栈的结构是一致的，所以可以使用堆栈中的全部信息。而在sys_open中参数filename, flags, mode正好对应与堆栈中的ebx, ecx, edx的位置，而这些寄存器正是用户在通过C库调用系统调用时给这些参数指定的寄存器。

        

__asm__ __volatile__(\

        

"int $0x80\n\t"\

        

:"=a"(retval)\

        

:"0"(__NR_open),\

        

"b"(filename),\

        

"c"(flags),\

        

"d"(mode));

        

　
        3.核心如何使用用户空间的参数

    

    

        
            #define __NR_hello ???（这个数字可能因为核心版本不同而不同）
            2.在某个合适的目录中（如：linux/kernel）增加一个hello.c，修改该目录下的Makefile（把相映的.o文件列入Makefile中就可以了）。
            3.编写hello.c            

. . . . . .

            

asmlinkage int sys_hello(char * str)

            

{

            

printk(“My syscall: hello, I know what you say to me: %s ! \n”, str);

            

return 0;

            

}

            

　
            4.修改linux/arch/i386/kernel/entry.S，在里面增加一条语句：

            

ENTRY(sys_call_table)

            

. . . . . .

            

.long SYMBOL_NAME(sys_hello)

            

并且修改：

            

.rept NR_syscalls-??? /* ??? = ??? +1 */

            

.long SYMBOL_NAME(sys_ni_syscall)
            5.在linux/include/i386/中增加hello.h，里面至少应包括这样几条语句：

        

    

        
• Linux中的系统调用

    

1． 进程相关的系统调用
        Fork & vfork & clone        

    进程是一个指令执行流及其执行环境，其执行环境是一个系统资源的集合，这些资源在Linux中被抽象成各种数据对象：进程控制块、虚存空间、文件系统，文件I/O、信号处理函数。所以创建一个进程的过程就是这些数据对象的创建过程。

        

    在调用系统调用fork创建一个进程时，子进程只是完全复制父进程的资源，这样得到的子进程独立于父进程，具有良好的并发性，但是二者之间的通讯需要通过专门的通讯机制，如：pipe，fifo，System V IPC机制等，另外通过fork创建子进程系统开销很大，需要将上面描述的每种资源都复制一个副本。这样看来，fork是一个开销十分大的系统调用，这些开销并不是所有的情况下都是必须的，比如某进程fork出一个子进程后，其子进程仅仅是为了调用exec执行另一个执行文件，那么在fork过程中对于虚存空间的复制将是一个多余的过程（由于Linux中是采取了copy-on-write技术，所以这一步骤的所做的工作只是虚存管理部分的复制以及页表的创建，而并没有包括物理也面的拷贝）；另外，有时一个进程中具有几个独立的计算单元，可以在相同的地址空间上基本无冲突进行运算，但是为了把这些计算单元分配到不同的处理器上，需要创建几个子进程，然后各个子进程分别计算最后通过一定的进程间通讯和同步机制把计算结果汇总，这样做往往有许多格外的开销，而且这种开销有时足以抵消并行计算带来的好处。

        

　

        

    这说明了把计算单元抽象到进程上是不充分的，这也就是许多系统中都引入了线程的概念的原因。在讲述线程前首先介绍以下vfork系统调用，vfork系统调用不同于fork，用vfork创建的子进程共享地址空间，也就是说子进程完全运行在父进程的地址空间上，子进程对虚拟地址空间任何数据的修改同样为父进程所见。但是用vfork创建子进程后，父进程会被阻塞直到子进程调用exec或exit。这样的好处是在子进程被创建后仅仅是为了调用exec执行另一个程序时，因为它就不会对父进程的地址空间有任何引用，所以对地址空间的复制是多余的，通过vfork可以减少不必要的开销。

        

    在Linux中， fork和vfork都是调用同一个核心函数

        

    do_fork(unsigned long clone_flag, unsigned long usp, struct pt_regs)

        

    其中clone_flag包括CLONE_VM, CLONE_FS, CLONE_FILES, CLONE_SIGHAND, CLONE_PID，CLONE_VFORK等等标志位，任何一位被置1了则表明创建的子进程和父进程共享该位对应的资源。所以在vfork的实现中，cloneflags = CLONE_VFORK | CLONE_VM | SIGCHLD，这表示子进程和父进程共享地址空间，同时do_fork会检查CLONE_VFORK，如果该位被置1了，子进程会把父进程的地址空间锁住，直到子进程退出或执行exec时才释放该锁。

        

　

        

    在讲述clone系统调用前先简单介绍线程的一些概念。

        

    线程是在进程的基础上进一步的抽象，也就是说一个进程分为两个部分：线程集合和资源集合。线程是进程中的一个动态对象，它应该是一组独立的指令流，进程中的所有线程将共享进程里的资源。但是线程应该有自己的私有对象：比如程序计数器、堆栈和寄存器上下文。

        

    线程分为三种类型：

        

    内核线程、轻量级进程和用户线程。

        

内核线程：

        

    它的创建和撤消是由内核的内部需求来决定的，用来负责执行一个指定的函数，一个内核线程不需要和一个用户进程联系起来。它共享内核的正文段核全局数据，具有自己的内核堆栈。它能够单独的被调度并且使用标准的内核同步机制，可以被单独的分配到一个处理器上运行。内核线程的调度由于不需要经过态的转换并进行地址空间的重新映射，因此在内核线程间做上下文切换比在进程间做上下文切换快得多。

        

轻量级进程：

        

    轻量级进程是核心支持的用户线程，它在一个单独的进程中提供多线程控制。这些轻量级进程被单独的调度，可以在多个处理器上运行，每一个轻量级进程都被绑定在一个内核线程上，而且在它的生命周期这种绑定都是有效的。轻量级进程被独立调度并且共享地址空间和进程中的其它资源，但是每个LWP都应该有自己的程序计数器、寄存器集合、核心栈和用户栈。

        

用户线程：

        

    用户线程是通过线程库实现的。它们可以在没有内核参与下创建、释放和管理。线程库提供了同步和调度的方法。这样进程可以使用大量的线程而不消耗内核资源，而且省去大量的系统开销。用户线程的实现是可能的，因为用户线程的上下文可以在没有内核干预的情况下保存和恢复。每个用户线程都可以有自己的用户堆栈，一块用来保存用户级寄存器上下文以及如信号屏蔽等状态信息的内存区。库通过保存当前线程的堆栈和寄存器内容载入新调度线程的那些内容来实现用户线程之间的调度和上下文切换。

        

    内核仍然负责进程的切换，因为只有内核具有修改内存管理寄存器的权力。用户线程不是真正的调度实体，内核对它们一无所知，而只是调度用户线程下的进程或者轻量级进程，这些进程再通过线程库函数来调度它们的线程。当一个进程被抢占时，它的所有用户线程都被抢占，当一个用户线程被阻塞时，它会阻塞下面的轻量级进程，如果进程只有一个轻量级进程，则它的所有用户线程都会被阻塞。

        

　

        

    明确了这些概念后，来讲述Linux的线程和clone系统调用。

        

    在许多实现了MT的操作系统中（如：Solaris，Digital Unix等）， 线程和进程通过两种数据结构来抽象表示： 进程表项和线程表项，一个进程表项可以指向若干个线程表项， 调度器在进程的时间片内再调度线程。  但是在Linux中没有做这种区分，  而是统一使用task_struct来管理所有进程/线程，只是线程与线程之间的资源是共享的，这些资源可是是前面提到过的：虚存、文件系统、文件I/O以及信号处理函数甚至PID中的几种。

        


            也就是说Linux中，每个线程都有一个task_struct，所以线程和进程可以使用同一调度器调度。其实Linux核心中，轻量级进程和进程没有质上的差别，因为Linux中进程的概念已经被抽象成了计算状态加资源的集合，这些资源在进程间可以共享。如果一个task独占所有的资源，则是一个HWP，如果一个task和其它task共享部分资源，则是LWP。

        

    clone系统调用就是一个创建轻量级进程的系统调用：

        

    int clone(int (*fn)(void * arg), void *stack, int flags, void * arg);

        

    其中fn是轻量级进程所执行的过程，stack是轻量级进程所使用的堆栈，flags可以是前面提到的CLONE_VM, CLONE_FS, CLONE_FILES, CLONE_SIGHAND,CLONE_PID的组合。Clone 和fork，vfork在实现时都是调用核心函数do_fork。

        

    do_fork(unsigned long clone_flag, unsigned long usp, struct pt_regs)；

        

    和fork、vfork不同的是，fork时clone_flag = SIGCHLD；

        

    vfork时clone_flag = CLONE_VM | CLONE_VFORK | SIGCHLD；

        

    而在clone中，clone_flag由用户给出。

        

    下面给出一个使用clone的例子。

        

    Void * func(int arg)

        

    {

        

    . . . . . .

        

    }

        

    int main()

        

    {

        

int clone_flag, arg;

        

. . . . . .

        

clone_flag = CLONE_VM | CLONE_SIGHAND | CLONE_FS |

        

CLONE_FILES;

        

stack = (char *)malloc(STACK_FRAME);

        

stack += STACK_FRAME;

        

retval = clone((void *)func, stack, clone_flag, arg);

        

. . . . . .

        

}

        

    看起来clone的用法和pthread_create有些相似，两者的最根本的差别在于clone是创建一个LWP，对核心是可见的，由核心调度，而pthread_create通常只是创建一个用户线程，对核心是不可见的，由线程库调度。

        

　

        

Nanosleep & sleep

        

    sleep和nanosleep都是使进程睡眠一段时间后被唤醒，但是二者的实现完全不同。

        

    Linux中并没有提供系统调用sleep，sleep是在库函数中实现的，它是通过调用alarm来设定报警时间，调用sigsuspend将进程挂起在信号SIGALARM上，sleep只能精确到秒级上。

        

    nanosleep则是Linux中的系统调用，它是使用定时器来实现的，该调用使调用进程睡眠，并往定时器队列上加入一个time_list型定时器，time_list结构里包括唤醒时间以及唤醒后执行的函数，通过nanosleep加入的定时器的执行函数仅仅完成唤醒当前进程的功能。系统通过一定的机制定时检查这些队列（比如通过系统调用陷入核心后，从核心返回用户态前，要检查当前进程的时间片是否已经耗尽，如果是则调用schedule()函数重新调度，该函数中就会检查定时器队列，另外慢中断返回前也会做此检查），如果定时时间已超过，则执行定时器指定的函数唤醒调用进程。当然，由于系统时间片可能丢失，所以nanosleep精度也不是很高。

        

    alarm也是通过定时器实现的，但是其精度只精确到秒级，另外，它设置的定时器执行函数是在指定时间向当前进程发送SIGALRM信号。

        

　
        2.存储相关的系统调用

    

vm_ops: open, close, no_page, swapin, swapout . . . . . .

            进程间通讯可以通过很多种机制，包括signal, pipe, fifo, System V IPC, 以及socket等等，前几种概念都比较好理解，这里着重介绍关于System V IPC。        

    System V IPC包括三种机制：message（允许进程发送格式化的数据流到任意的进程）、shared memory（允许进程间共享它们虚拟地址空间的部分区域）和semaphore（允许进程间同步的执行）。

        

    操作系统核心中为它们分别维护着一个表，这三个表是系统中所有这三种IPC对象的集合，表的索引是一个数值ID，进程通过这个ID可以查找到需要使用的IPC资源。进程每创建一个IPC对象，系统中都会在相应的表中增加一项。之后其它进程（具有许可权的进程）只要通过该IPC对象的ID则可以引用它。

        

    IPC对象必须使用IPC_RMID命令来显示的释放，否则这个对象就处于活动状态，甚至所有的使用它的进程都已经终止。这种机制某些时候十分有用，但是也正因为这种特征，使得操作系统内核无法判断IPC对象是被用户故意遗留下来供将来其它进程使用还是被无意抛弃的。

        

    Linux中只提供了一个系统调用接口ipc()来完成所有System V IPC操作，我们常使用的是建立在该调用之上的库函数接口。对于这三种IPC，都有很相似的三种调用：xxxget, (msgsnd, msgrcv)｜semopt | (shmat, shmdt), xxxctl

        

    Xxxget：获取调用，在系统中申请或者查询一个IPC资源，返回值是该IPC对象的ID，该调用类似于文件系统的open, create调用；

        

    Xxxctl：控制调用，至少包括三种操作:XXX_RMID（释放IPC对象）, XXX_STAT（查询状态）, XXX_SET（设置状态信息）；

        

    (msgsnd, msgrcv) | Semopt | (shmat, shmdt)|：操作调用，这些调用的功能随IPC对象的类型不同而有较大差异。

        

4.文件系统相关的调用

        

    文件是用来保存数据的，而文件系统则可以让用户组织，操纵以及存取不同的文件。内核允许用户通过一个严格定义的过程性接口与文件系统进行交互，这个接口对用户屏蔽了文件系统的细节，同时指定了所有相关系统调用的行为和语义。Linux支持许多中文件系统，如ext2，msdos, ntfs, proc, dev, ufs, nfs等等，这些文件系统都实现了相同的接口，因此给应用程序提供了一致性的视图。但每种文件系统在实现时可能对某个方面加以了一定的限制。如：文件名的长度，是否支持所有的文件系统接口调用。

        

    为了支持多文件系统，sun提出了一种vnode/vfs接口，SVR4中将之实现成了一种工业标准。而Linux作为一种Unix的clone体，自然也实现了这种接口，只是它的接口定义和SVR4的稍有不同。Vnode/Vfs接口的设计体现了面向对象的思想，Vfs（虚拟文件系统）代表内核中的一个文件系统，Vnode（虚拟节点）代表内核中的一个文件，它们都可以被视为抽象基类，并可以从中派生出不同的子类以实现不同的文件系统。

        

    由于篇幅原因，这里只是大概的介绍一下怎样通过Vnode/Vfs结构来实现文件系统和访问文件。

        

    在Linux中支持的每种文件系统必须有一个file_system_type结构，此结构的核心是read_super函数，该函数将读取文件系统的超级块。Linux中支持的所有文件系统都会被注册在一条file_system_type结构链中，注册是在系统初始化时调用regsiter_filesystem()完成，如果文件系统是以模块的方式实现，则是在调用init_module时完成。

        


            当mount某种块设备时，将调用系统调用mount，该调用中将会首先检查该类文件系统是否注册在系统种中，如果注册了则先给该文件系统分配一个super_block，并进行初始化，最后调用这种文件系统的read_super函数来完成super_block结构私有数据的赋值。其中最主要的工作是给super_block的s_ops赋值，s_ops是一个函数向量表，由文件系统各自实现了一组操作。

        

struct super_operations {

        

void (*read_inode) (struct inode *);

        

void (*write_inode) (struct inode *);

        

void (*put_inode) (struct inode *);

        

void (*delete_inode) (struct inode *);

        

void (*put_super) (struct super_block *);

        

void (*write_super) (struct super_block *);

        

int (*statfs) (struct super_block *, struct statfs *);

        

int (*remount_fs) (struct super_block *, int *, char *);

        

void (*clear_inode) (struct inode *);

        

void (*umount_begin) (struct super_block *);

        

};

        

    由于这组操作中定义了文件系统中对于inode的操作，所以是之后对于文件系统中文件所有操作的基础。

        

    在给super_block的s_ops赋值后，再给该文件系统分配一个vfsmount结构，将该结构注册到系统维护的另一条链vfsmntlist中，所有mount上的文件系统都在该链中有一项。在umount时，则从链中删除这一项并且释放超级块。

        

    对于一个已经mount的文件系统中任何文件的操作首先应该以产生一个inode实例，即根据文件系统的类型生成一个属于该文件系统的内存i节点。这首先调用文件定位函数lookup_dentry查找目录缓存看是否使用过该文件，如果还没有则缓存中找不到，于是需要的i接点则依次调用路径上的所有目录I接点的lookup函数，在lookup函数中会调用iget函数，该函数中最终调用超级块的s_ops->read_inode读取目标文件的磁盘I节点（这一步再往下就是由设备驱动完成了，通过调用驱动程序的read函数读取磁盘I节点），read_inode函数的主要功能是初始化inode的一些私有数据(比如数据存储位置，文件大小等等)以及给inode_operations函数开关表赋值，最终该inode被绑定在一个目录缓存结构dentry中返回。

        

    在获得了文件的inode之后，对于该文件的其它一切操作都有了根基。因为可以从inode 获得文件操作函数开关表file_operatoins，该开关表里给出了标准的文件I/O接口的实现，包括read, write, lseek, mmap, ioctl等等。这些函数入口将是所有关于文件的系统调用请求的最终处理入口，通过这些函数入口会向存储该文件的硬设备驱动发出请求并且由驱动程序返回数据。当然这中间还会牵涉到一些关于buffer的管理问题，这里就不赘述了。

        

    通过讲述这些，我们应该明白了为什么可以使用统一的系统调用接口来访问不同文件系统类型的文件了：因为在文件系统的实现一层，都把低层的差异屏蔽了，用户可见的只是高层可见的一致的系统调用接口。

        

　
        5.与module相关的系统调用

    

        
• Linux中怎样编译和定制内核

    

1.编译内核前注意的事项        

    检查系统上其它资源是否符合新内核的要求。在linux/Document目录下有一个叫Changes的文件，里面列举了当前内核版本所需要的其它软件的版本号，

        

– Kernel modutils             2.1.121                           ; insmod -V

        

– Gnu C                       2.7.2.3                           ; gcc –version

        

– Binutils                    2.8.1.0.23                        ; ld -v

        

– Linux libc5 C Library       5.4.46                            ; ls -l /lib/libc*

        

– Linux libc6 C Library       2.0.7pre6                         ; ls -l /lib/libc*

        

– Dynamic Linker (ld.so)      1.9.9                             ; ldd –version or ldd -v

        

– Linux C++ Library           2.7.2.8                           ; ls -l /usr/lib/libg++.so.*

        

. . . . . .

        

其中最后一项是列举该软件版本号的命令，如果不符合要求先给相应软件升级，这一步通常可以忽略。

        

2.配置内核

        

    使用make config或者make menuconfig, make xconfig配置新内核。其中包括选择块设备驱动程序、网络选项、网络设备支持、文件系统等等，用户可以根据自己的需求来进行功能配置。每个选项至少有“y”和“n”两种选择，选择“y”表示把相应的支持编译进内核，选“n”表示不提供这种支持，还有的有第三种选择“m”，则表示把该支持编译成可加载模块，即前面提到的module，怎样编译和安装模块在后面会介绍。

        

    这里，顺便讲述一下如何在内核中增加自己的功能支持。

        

    假如我们现在需要在自己的内核中加入一个文件系统tfile，在完成了文件系统的代码后，在linux/fs下建立一个tfile目录，把源文件拷贝到该目录下，然后修改linux/fs下的Makefile，把对应该文件系统的目标文件加入目标文件列表中，最后修改linux/fs/Config.in文件，加入

        

bool ‘tfile fs support’ CONFIG_TFILE_FS或者

        

tristate ‘tfile fs support’ CONFIG_TFILE_FS

        

这样在Make menuconfig时在filesystem选单下就可以看到

        

< > tfile fs support一项了

        

3.编译内核

        

    在配置好内核后就是编译内核了，在编译之前首先应该执行make dep命令建立好依赖关系，该命令将会修改linux中每个子目录下的.depend文件，该文件包含了该目录下每个目标文件所需要的头文件（绝对路径的方式列举）。

        

    然后就是使用make bzImage命令来编译内核了。该命令运行结束后将会在linux/arch/asm/boot/产生一个名叫bzImage的映像文件。

        

4.使用新内核引导

        

    把前面编译产生的映像文件拷贝到/boot目录下（也可以直接建立一个符号连接，这样可以省去每次编译后的拷贝工作），这里暂且命名为vmlinuz-new，那么再修改/etc/lilo.conf，在其中增加这么几条：

        

image = /boot/vmlinuz-new

        

root = /dev/hda1

        

label = new

        

read-only

        

并且运行lilo命令，那么系统在启动时就可以选用新内核引导了。

        

5.编译模块和使用模块