当用户态的进程调用一个系统调用时，CPU切换到内核态并开始执行一个内核函数。在X86体系中，可以通过两种不同的方式进入系统调用：执行int $0x80汇编命令和执行sysenter汇编命令。后者是Intel在PentiumII中引入的指令，内核从2.6版本开始支持这条命令。本文将集中讨论以int $0x80方式进入系统调用的过程。

通过int $0x80方式调用系统调用实际上是用户进程产生一个中断向量号为0x80的软中断。当用户态进程发出int $0x80指令时，CPU将从用户态切换到内核态并开始执行system_call()。这个函数是通过汇编命令来实现的，它是0x80号软中断对应的中断处理程序。对于所有系统调用来说，它们都必须先进入system_call()，也就是所谓的系统调用处理程序。再通过系统调用号跳转到具体的系统调用服务例程处。

在该函数执行之前，CPU控制单元已经将eflags、cs、eip、ss和esp寄存器的值自动保存到该进程对应的内核栈中。随之，在system_call内部首先将存储在eax寄存器中的系统调用号压入栈中。接着执行SAVE_ALL宏。该宏在栈中保存接下来的系统调用可能要用到的所有CPU寄存器。

通过GET_THREAD_INFO宏获得当前进程的thread_inof结构的地址；再检测当前进程是否被其他进程所跟踪，也就是thread_inof结构中flag字段的_TIF_SYSCALL_TRACE或_TIF_SYSCALL_AUDIT被置1。如果发生被跟踪的情况则转向相应的处理命令处。

接着，对用户态进程传递过来的系统调用号的合法性进行检查。如果不合法则跳入到syscall_badsys标记的命令处。

如果系统调用好合法，则跳入相应系统调用号所对应的服务例程当中，也就是在sys_call_table表中找到了相应的函数入口点。由于sys_call_table表的表项占4字节，因此获得服务例程指针的具体方法是将由eax保存的系统调用号乘以4再与sys_call_table表的基址相加。

当系统调用服务例程结束时，从eax寄存器中获得当前进程的的返回值，并把这个返回值存放在曾保存用户态eax寄存器值的那个栈单元的位置上。这样，用户态进程就可以在eax寄存器中找到系统调用的返回码。

至此，用户进程进入系统调用的过程大致分析完毕。

如何往内核中添加自己写的系统调用？其实步骤非常简单：

1.编写一个系统调用；
2.在系统调用表末尾加入一个新表项；
3.在< asm/unistd.h >中添加一个新的系统调用号；
4.重新编译内核；

上述工作完成后，就可以在用户程序中使用自己所编写的系统调用了。接下来，我们将逐步分析如何上述步骤。

1.编写系统调用

我们将要实现一个获得当前进程pid的的系统调用。对于一个进程，我们可以直接通过current->pid来获得。为了使得这个系统调用同样适用于一个线程，我们使用current->tgid。这么做的原因是同一个线程组内的所有线程TGID均相同；而一个进程的PID和TGID是相同的。

与普通函数不同的是，这个系统调用的函数名前有asmlinkage修饰符。这个修饰符使得GCC编译器从堆栈中取该函数的参数而不是寄存器中。另外，系统调用函数的命名规则都是sys_XXX的形式。

接下来，我们的要做的是将这个函数放于何处。一种方法是，将上述函数放于/kernel/下的某个文件中；另一种方式是，将这个函数单独存放在/kernel/下的一个新建的.c文件中。不管何种方法，所做的目的都是为了在重新编译内核时将上述我们所编写的系统调用函数编译进内核。

2.在系统调用表中添加新的表项

linux中为每一个系统调用都分配一个系统调用号。也就是说，每一个系统调用号都唯一的对应着一个系统调用。内核中使用系统调用表来记录所有已经注册过的系统调用，这个系统调用表存储在sys_call_table中。在yoursource/arch/x86/kernel/syscall_table_32.S中可以看到系统系统调用表。

我们所要做的就是在该表的末尾添加我们刚编写的系统调用：.long sys_getpid。我们并不需要显式的指定系统调用号，从0开始算起，我们所编写的函数的系统调用号为341。

3.在< asm/unistd.h >中添加一个新的系统调用号

上一步，在系统调用表中添加新的表项是为了将系统调用号和系统调用关联起来。现在，我们需要在unistd.h文件中添加具体的系统调用号，这样使得系统可以根据这个系统调用号在系统调用表中查找具体的系统调用。

当用户进程调用一个系统调用时，其实是通过一个中断号为128的软中断来通知内核的。此时，内核会由用户态切换到内核态转而去执行这个软中断对应的中断处理程序。而这个中断处理程序恰好就是系统调用处理程序。也就是说，任何系统调用都会引发CPU去执行这个系统调用处理程序。因此，必须通过系统调用号来识别不同的系统调用。系统调用号通常会存储在eax寄存器中。

现在我们就在yoursource/arch/x86/include/asm/unistd_32.h文件中添加新的系统调用号。在上一步我们所添加的sys_mygetpid系统调用对应的编号为341，因此我们在该文件的末尾添加下面的语句：#define __NR_mygetpid 341。注意这里的宏命名规则，以__NR_开头。

4.编译内核

如果上述三个步骤都完成后，那么接下来重新编译内核即可。具体可参见这里。

5.编写用户态的程序

上述用户程序可能与我们平日里所写的稍有不同。主要区别是增加了_syscall0(int,mygetpid)这个宏。因为我们现在直接在程序中调用系统调用，而我们平时则是通过调用C库中的API来间接调用系统调用。在unistd.h文件中有_syscallN()宏的定义，这里的N可取0～6。N代表的是需要传递给系统调用的参数个数。由于mygetpid系统调用需传递的参数个数为0，因此选取_syscall0。另外，这组宏的内部参数分布有如下特点：第一个参数是系统调用返回值的类型，第二个参数是系统调用函数的名称，接下来的参数按照系统调用参数的次序依次是参数类型和参数名称。对于每个宏来说，都有2+2*N个参数。

OK，上述方法即可以将我们自己编写的系统调用函数加入到内核。try！

update: 2011/09/21

1.系统调用

我们知道，Linux将整个虚拟地址空间划分为两部分：用户空间和内核空间。并且规定，用户空间不能直接访问内核空间，而内核空间则可以访问用户空间。通过这样的级别划分，可以使得内核空间更加的稳定和安全。但是，当用户进程必须访问内核或使用某个内核函数时，就得使用系统调用（System Call）。在Linux中，系统调用是用户空间访问内核空间的唯一途径。

系统调用是内核提供的一组函数接口，它使得用户空间上运行的进程可以和内核之间进行交互。比如，用户进程通过系统调用访问硬件设备或操作系统的某些资源等。系统调用如同内核空间和用户空间的一个传话者。内核如同一个高高在上的帝王，而用户空间的进程则属于级别很小的官员。由于用户进程资质太浅，当它需要得到内核的支持时，它并没有权利直接上报内核，而只能通过系统调用这个传话人来得到内核的支持。

具体的，用户程序通过应用编程接口来使用系统调用，而系统调用则是在内核中通过内核函数来实现的。

2.应用编程接口

应用编程接口（Application Programming Interface，API）其实就是程序员在用户空间下可以直接使用的函数接口。每个API会对应一定的功能。比如strlen()，它所实现的功能就是求所传递字符串的长度。

有时候，某些API所提供的功能会涉及到与内核空间进行交互。那么，这类API内部会封装系统调用。而不涉及与内核进行交互的API则不会封装系统调用。也就是说，API和系统调用并没有严格对应关系，一个API可能恰好只对应一个系统调用，比如read()API和read()系统调用；一个API也可能由多个系统调用实现；有时候，一个API的功能可能并不需要内核提供的服务，那么此时这个API也就不需要任何的系统调用，比如abs()。另外，一个系统调用可能还被多个不同的API内部调用。

对于编程者来说，系统调用和API都是一组函数，并无什么两样；但是事实上，系统调用的实现是在内核完成的，API则是在函数库中实现的。

API是用户程序直接可以使用的函数接口，但如果每个操作系统都拥有只属于自己的API，那么应用程序的移植性将会很差。基于POSIX（Portable Operating System Interface）标准的API拥有很好的可移植性，它定义了一套POSIX兼容标准，这使得按这个标准实现的API可以在各种版本的UNIX中使用。现如今，它也可以在除UNIX之外的操作系统中使用，比如Linux，Windows NT等。

3.函数库

一个.c文件会经过预处理、编译、汇编、链接四个步骤。在汇编阶段，输出的是.o文件，即我们常说的目标文件。目标文件并不能直接执行，它需要链接器的再一次加工。链接器将所有的目标文件集合在一起，加上库文件，最后才能得到可执行文件。

函数库完成了各种API函数的定义，只不过函数库是二进制的形式，我们不能直接去查看这些API函数如何实现。这些API函数的声明则散步在不同的头文件中，比如我们常用（也许你并未感知我们频繁的使用这个函数库）的标准函数库libc.so，在其中包含多个我们常用的函数定义，但是这些函数的声明却分布在stdio.h和string.h等头文件中。

我们每次在链接程序时，都必须告诉链接器需要链接到那个库中。只不过通常默认的链接让我们忽视了这一点。

比如，一个简单的helloworld程序中，仅使用了stdio.h头文件。我们当然可以这样轻松的编译：gcc helloworld.c -o helloworld。之所以可以毫无顾忌是因为stdio.h中所声明的函数都定义在libc.so中，而对于这个函数库，连接器是默然链接的。

如果我们编译如下程序：

按照我们以往的编译方法显然是不行的：

因为在这个程序中使用了math.h头文件，而这个头文件中声明的函数sqrt()被定义在libm.so函数库中。那么，这个时候应该这样编译：gcc test.c -o test -lm。最后的-lm选项即告诉链接器需要加入libm.so函数库。

上述一步到位的编译方法似乎又无形中掩盖了函数库的加入时间。如果我们按照编译程序的四个步骤依次处理相应文件时，就可以发现只有到了最后的链接过程中才会出现上述错误信息。也就是说，函数库的加入是在链接部分。

从上述内容中，我们知道应用程序直接使用的并不是系统调用（不过可以通过_syscallN的方法直接使用系统调用）而是API。内核中提供的每个系统调用都通过libc库封装成相应的API。如果一个API函数中包含系统调用，那么它通常在libc库中会对应一个封装例程（wrapper routine）。封装例程可能正好对应一个与API同名的系统调用，有时为了实现更加复杂的功能会封装多个系统调用。

4.系统命令

每一个系统命令其实就是一个可执行的程序，这些可执行程序的实现调用了某些系统调用。并且，这些可执行程序又分为普通用户可使用的命令和管理员可使用的命令。根据上述分类，普通用户可用的命令和管理可用的命令分别被存放于/bin和/sbin目录下。

5.系统调用的服务例程

系统调用的实现是在内核中完成的，它通过封装对应的内核函数（通常是以sys_开头，再加上相应的系统调用名）来实现其代表的功能。内核函数和用户空间中函数并无两样，只不过内核函数是在内核中实现。也就是说，用户程序通过某个系统调用进入内核后，会接着去执行这个系统调用对应的内核函数。这个内核函数也称为系统调用的服务例程。

由于内核函数是在内核中实现的，因此它必须符合内核编程的规则，比如函数名以sys_开始，函数定义时候需加asmlinkage标识符等。