细说系统调用规范，入行要先熟悉套路

用是操作系统内核提供给应用程序的基础接口，需要运行在操作系统的核心模式下，以确保有权限执行某些 CPU 特权指令。

Linux 系统提供了功能非常丰富的系统调用，涵盖了文件操作、进程控制、内存管理、网络管理、套接字操作、用户管理、进程间通信等各个方面。

执行如下命令，可列出系统中所有的系统调用名称。 自带的 man 手册对每个系统调用都进行了非常详细的说明，包括函数功能、传入的参数、返回值，以及可能产生的错误、使用注意事项，等等，其完善程度丝毫不亚于微软的 MSDN。虽然是英文版，但读起来比较通俗易懂，每位 Linux 系统开发者都应该习惯于查看这些文档。

另外，IBM 文档库里有一份质量非常高的《中文版系统调用列表》，阅读它会更轻松。

1.2 系统调用的两种调用方式

我们先看一种方式。

系统调用由指派的编号来标识，通过 syscall 函数以编号为参数可直接被调用。

syscall 函数原型为：统调用编号都定义在 sys/syscall.h 的文件中。感兴趣的读者可以自行查看。

显然，记忆如此多的编号，对开发者很不友好。

于是，开发者多会选择第二种方式，即利用 glibc 提供的包装函数将这些系统调用包装成名字自解释的函数。

这个过程，包装函数并没有做太多额外工作，主要是检查参数，将它们拷贝到合适的寄存器中，接着调用指定标号的系统调用，之后再根据结果设置 errno，供应用程序检查执行结果，以及其他相关工作。

两种调用方式，在功能上可以认为是完全等价的，但在易读、易用性上，glibc 包装函数则更有优势。在之后的课程中，我提到某系统调用，若无特殊说明，指的便是 glibc 包装函数。

当然，如果包装函数无法满足某些特殊应用场景需求，还可以使用 syscall 函数直接执行系统调用。不过这种情况非常少见，到目前为止，我还没有遇到过。

1.3 系统调用的两种执行过程

1.3.1 基于中断方式

系统调用的实现代码是内核代码的一部分。执行系统调用代码，首先需要将系统从用户模式切换到核心模式。

早期的系统调用通过软中断实现模式的切换，而中断号属于系统稀缺资源，不可能为每个系统调用都分配一个中断号。

在 Linux 的实现中，所有的系统调用共用 128 号中断(也就是大名鼎鼎的 int 0x80 )，其对应的中断处理程序是 system_call，所有的系统调用都会转到这个中断处理程序中。

接着，system_call 会根据 EAX 传入的系统调用标号跳转并执行相应的系统调用程序。如果需要更多的参数，会依次用 EBX、ECX、EDX、EDI 进行传递。函数执行完成之后，会把结果放到 EAX 中返回给应用程序。

由此可知，一次系统调用便会触发一次完整的中断处理过程。在每次中断处理过程中，CPU 都会从系统启动时初始化好的中断描述表中，取出该中断对应的门描述符，并判断门描述符的种类。

在确认门描述符的级别(DPL)不比中断指令调用者的级别(CPL)低之后，再根据描述符的内容，将中断处理程序中可能用到的寄存器进行压栈保存。然后，执行权限提升，设置 CS 和 EIP 寄存器，以使 CPU 跳转到指定的系统调用的代码地址，并执行目标系统调用

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!