如何使用系统调用

mind

如何使用系统调用

如图5.2所示，用户应用可以通过两种方式使用系统调用。第一种方式是通过C库函数，包括系统调用在C库中的封装函数和其他普通函数。

图5.2  使用系统调用的两种方式

第二种方式是使用_syscall宏。2.6.18版本之前的内核，在include/asm-i386/unistd.h文件中定义有7个_syscall宏，分别是：

复制

其中，type表示所生成系统调用的返回值类型，name表示该系统调用的名称，typeN、argN分别表示第N个参数的类型和名称，它们的数目和_syscall后面的数字一样大。这些宏的作用是创建名为name的函数，_syscall后面跟的数字指明了该函数的参数的个数。

比如sysinfo系统调用用于获取系统总体统计信息，使用_syscall宏定义为：

复制

展开后的形式为：

复制

可以看出，_syscall1(int, sysinfo, struct sysinfo *, info)展开成一个名为sysinfo的函数，原参数int就是函数的返回类型，原参数struct sysinfo *和info分别构成新函数的参数。

在程序文件里使用_syscall宏定义需要的系统调用，就可以在接下来的代码中通过系统调用名称直接调用该系统调用。下面是一个使用sysinfo系统调用的实例。

代码清单5.1  sysinfo系统调用使用实例

复制

但是自2.6.19版本开始，_syscall宏被废除，要使用syscall函数，通过指定系统调用号和一组参数来调用系统调用。

syscall函数原型为：

复制

其中number是系统调用号，number后面应顺序接上该系统调用的所有参数。下面是gettid系统调用的调用实例。

代码清单5.2  gettid系统调用使用实例。

复制

大部分系统调用都包括了一个SYS_符号常量来指定自己到系统调用号的映射，因此上面第10行可重写为：

复制

5.2 系统调用执行过程

系统调用的执行过程主要包括如图5.3与图5.4所示的两个阶段：用户空间到内核空间的转换阶段，以及系统调用处理程序system_call函数到系统调用服务例程的阶段。

   

图5.3  用户空间到内核空间

   

图5.4  system_call函数到系统调用服务例程

（1）用户空间到内核空间。

如图5.3所示，系统调用的执行需要一个用户空间到内核空间的状态转换，不同的平台具有不同的指令可以完成这种转换，这种指令也被称作操作系统陷入（operating system trap）指令。

Linux通过软中断来实现这种陷入，具体对于X86架构来说，是软中断0x80，也即int $0x80汇编指令。软中断和我们常说的中断（硬件中断）不同之处在于-它由软件指令触发而并非由硬件外设引发。

int 0x80指令被封装在C库中，对于用户应用来说，基于可移植性的考虑，不应该直接调用int $0x80指令。陷入指令的平台依赖性，也正是系统调用需要在C库进行封装的原因之一。

通过软中断0x80，系统会跳转到一个预设的内核空间地址，它指向了系统调用处理程序（不要和系统调用服务例程相混淆），即在arch/i386/kernel/entry.S文件中使用汇编语言编写的system_call函数。

（2）system_call函数到系统调用服务例程。

很显然，所有的系统调用都会统一跳转到这个地址进而执行system_call函数，但正如前面所述，到2.6.23版为止，内核提供的系统调用已经达到了325个，那么system_call函数又该如何派发它们到各自的服务例程呢？

软中断指令int 0x80执行时，系统调用号会被放入eax寄存器，同时，sys_call_table每一项占用4个字节。这样，如图5.5所示，system_call函数可以读取eax寄存器获得当前系统调用的系统调用号，将其乘以4生成偏移地址，然后以sys_call_table为基址，基址加上偏移地址所指向的内容即是应该执行的系统调用服务例程的地址。

另外，除了传递系统调用号到eax寄存器，如果需要，还会传递一些参数到内核，比如write系统调用的服务例程原型为：

复制

调用write系统调用时就需要传递文件描述符fd、要写入的内容buf以及写入字节数count等几个内容到内核。ebx、ecx、edx、esi以及edi寄存器可以用于传递这些额外的参数。

正如之前所述，系统调用服务例程定义中的asmlinkage标记表示，编译器仅从堆栈中获取该函数的参数，而不需要从寄存器中获得任何参数。进入system_call函数前，用户应用将参数存放到对应寄存器中，system_call函数执行时会首先将这些寄存器压入堆栈。

对于系统调用服务例程，可以直接从system_call函数压入的堆栈中获得参数，对参数的修改也可以一直在堆栈中进行。在system_call函数退出后，用户应用可以直接从寄存器中获得被修改过的参数。

并不是所有的系统调用服务例程都有实际的内容，有一个服务例程sys_ni_syscall除了返回-ENOSYS外不做任何其他工作，在kernel/sys_ni.c文件中定义。

复制

sys_ni_syscall的确是最简单的系统调用服务例程，表面上看，它可能并没有什么用处，但是，它在sys_call_table中占据了很多位置。多数位置上的sys_ni_syscal都代表了那些已经被内核中淘汰的系统调用，比如：

复制

就分别代替了已经废弃的stty和gtty系统调用。如果一个系统调用被淘汰，它所对应的服务例程就要被指定为sys_ni_syscall。

我们并不能将它们的位置分配给其他的系统调用，因为一些老的代码可能还会使用到它们。否则，如果某个用户应用试图调用这些已经被淘汰的系统调用，所得到的结果，比如打开了一个文件，就会与预期完全不同，这将令人感到非常奇怪。

其实，sys_ni_syscall中的"ni"即表示"not implemented（没有实现）"。

系统调用通过软中断0x80陷入内核，跳转到系统调用处理程序system_call函数，并执行相应的服务例程，但由于是代表用户进程，所以这个执行过程并不属于中断上下文，而是处于进程上下文。

因此，系统调用执行过程中，可以访问用户进程的许多信息，可以被其他进程抢占（因为新的进程可能使用相同的系统调用，所以必须保证系统调用可重入），可以休眠（比如在系统调用阻塞时或显式调用schedule函数时）。

这些特点涉及进程调度的问题，在此不做深究，读者只需要理解当系统调用完成后，把控制权交回到发起调用的用户进程前，内核会有一次调度。如果发现有优先级更高的进程或当前进程的时间片用完，那么就会选择高优先级的进程或重新选择进程运行。

5.3 系统调用示例

本节通过对几个系统调用的剖析来讲解它们的工作方式。

5.3.1  sys_dup

dup系统调用的服务例程为sys_dup函数，在fs/fcntl.c文件中定义如下。

代码清单5.3  dup系统调用的服务例程

复制

除了sys_ni_call()以外，sys_dup()称得上是最简单的服务例程之一，但是它却是Linux输入/输出重定向的基础。

在Linux中，执行一个shell命令时通常会自动打开3个标准文件：标准输入文件（stdin），通常对应终端的键盘；标准输出文件（stdout）和 标准错误输出文件（stderr），通常对应终端的屏幕。shell命令从标准输入文件中得到输入数据，将输出数据输出到标准输出文件，而将错误信息输出到标准错误文件中。

比如下面的命令：

复制

将把cpuinfo文件的内容显示到屏幕上，但是如果cat命令不带参数，则会从stdin中读取数据，并将其输出到stdout，比如：

复制

用户输入的每一行都将立刻被输出到屏幕上。

输入重定向是指把命令的标准输入重定向到指定的文件中，即输入可以不来自键盘，而来自一个指定的文件。所以说，输入重定向主要用于改变一个命令的输入源。

输出重定向是指把命令的标准输出或标准错误输出重新定向到指定文件中。这样，该命令的输出就不显示在屏幕上，而是写入到指定文件中。我们经常会利用输出重定向将程序或命令的log保存到指定的文件中。

那么sys_dup()又是如何完成输入/输出的重定向呢？下面通过一个例子进行说明。

当我们在shell终端下输入"echo hello"命令时，将会要求shell进程执行一个可执行文件echo，参数为"hello"。当shell进程接收到命令之后，先在/bin目录下找到echo文件（我们可以使用which命令获得命令所在的位置），然后创建一个子进程去执行/bin/echo，并将参数传递给它，而这个子进程从shell进程继承了3个标准输入/输出文件，即stdin、stdout和stderr，文件号分别为0、1、2。它的工作很简单，就是将参数"hello"写到stdout文件中，通常都是我们的屏幕上。

但是如果我们将命令改成"echo hello > txt"，则在执行时输出将会被重定向到磁盘文件txt中。假定之前该shell进程只有上述3个标准文件打开，则该命令将按如下序列执行。

（1）打开或创建文件txt，如果txt中原来有内容，则清除原来的内容，其文件号为3。

（2）通过dup系统调用复制文件stdout的相关数据结构到文件号4。

（3）关闭stdout，但是由于4号文件也同时引用stdout，所以stdout文件并未真正关闭，只是腾出1号文件号位置。

（4）通过dup系统调用，复制3号文件（即文件txt），由于1号文件关闭，其位置空缺，故3号文件被复制到1号，即进程中原来指向stdout的指针指向了txt。

（5）通过系统调用fork和exec创建子进程并执行echo，子进程在执行cat前关闭3号和4号文件，只留下0、1、2三个文件，请注意，这时的1号文件已经不是stdout而是文件txt了。当cat想向stdout文件写入"hello"时自然就写入到了txt中。

（6）回到shell进程后，关闭指向txt的1号与3号文件文件，再用dup和close系统调用将2号恢复至stdout，这样shell就恢复了0、1、2三个标准输入/输出文件。

5.3.2  sys_reboot

Linux下有关关机与重启的命令主要有shutdown、reboot、halt、poweroff、telinit和init。它们都可以达到关机或重启的目的，但是每个命令的工作流程并不一样。

这些命令并不都是互相独立的，比如，poweroff、reboot即是halt的符号链接，但是它们最终都是通过reboot系统调用来完成关机或重启操作。

reboot系统调用的服务例程为sys_reboot函数，在kernel/sys.c文件中定义如下。

代码清单5.4  reboot系统调用的服务例程

复制

顾名思义，reboot系统调用可以用于重新启动系统，但根据所提供的参数不同，它还能够完成关机、挂起系统、允许或禁止使用Ctrl+Alt+Del组合键重启等不同的操作。我们还要特别注意内核里对sys_reboot()的注释，在使用它之前首先要使用sync命令同步磁盘，否则磁盘上的文件系统可能会有所损坏。

第901行检查调用者是否有合法权限。capable函数用于检查是否有操作指定资源的权限，如果它返回非零值，则调用者有权进行操作，否则无权操作。比如，这一行的capable(CAP_SYS_BOOT)即检查调用者是否有权限使用reboot系统调用。

第905行～第910行通过对两个参数magic1和magic2的检测，判断reboot系统调用是不是被偶然调用到的。如果reboot系统调用是被偶然调用的，那么参数magic1和magic2几乎不可能同时满足预定义的这几个数字的集合。

从第919行开始，sys_reboot()对调用者的各种使用情况进行区分。为LINUX_REBOOT_CMD_RESTART时，kernel_restart()将打印出"Restarting system."消息，然后调用machine_restart函数重新启动系统。

为LINUX_REBOOT_CMD_CAD_ON或LINUX_REBOOT_CMD_CAD_OFF时，分别允许或禁止Ctrl+Alt+Del组合键。我们还可以在/etc/inittab文件指定是否可以使用Ctrl+Alt+Del组合键来关闭并重启系统。如果希望完全禁止这个功能，需要将/etc/inittab文件中的下面一行注释掉。

复制

为LINUX_REBOOT_CMD_HALT时，打印出"System halted."消息，和LINUX_REBOOT_CMD_RESTART情况下类似，但只是暂停系统而不是将其重新启动。

为LINUX_REBOOT_CMD_POWER_OFF时，打印出"Power down."消息，然后关闭机器电源。

为LINUX_REBOOT_CMD_RESTART2时，接收命令字符串，该字符串说明了系统应该如何关闭。

最后，LINUX_REBOOT_CMD_SW_SUSPEND用于使系统休眠。

5.4 系统调用的实现

一个系统调用的实现并不需要去关心如何从用户空间转换到内核空间，以及系统调用处理程序如何去执行，你需要做的只是遵循几个固定的步骤。

5.4.1  如何实现一个新的系统调用

为Linux添加新的系统调用是件相对容易的事情，主要包括有4个步骤：编写系统调用服务例程；添加系统调用号；修改系统调用表；重新编译内核并测试新添加的系统调用。

下面以一个并无实际用处的hello系统调用为例，来演示上述几个步骤。

（1）编写系统调用服务例程。

遵循前面所述的几个原则，hello系统调用的服务例程实现为：

复制

通常，应该为新的系统调用服务例程创建一个新的文件进行存放，但也可以将其定义在其他文件之中并加上注释做必要说明。同时，还要在include/linux/syscalls.h文件中添加原型声明：

复制

sys_hello函数非常简单，仅仅打印一条语句，并没有使用任何参数。如果我们希望hello系统调用不仅能打印"hello!"欢迎信息，还能够打印出我们传递过去的名称，或者其他的一些描述信息，则sys_hello函数可以实现为：

复制

第二个sys_hello函数使用了一个参数，在这种有参数传递发生的情况下，编写系统调用服务例程时必须仔细检查所有的参数是否合法有效。因为系统调用在内核空间执行，如果不加限制任由用户应用传递输入进入内核，则系统的安全与稳定将受到影响。

参数检查中最重要的一项就是检查用户应用提供的用户空间指针是否有效。比如上述sys_hello函数参数为char类型指针，并且使用了__user标记进行修饰。__user标记表示所修饰的指针为用户空间指针，不能在内核空间直接引用，原因主要如下。

用户空间指针在内核空间可能是无效的。

用户空间的内存是分页的，可能引起页错误。

如果直接引用能够成功，就相当于用户空间可以直接访问内核空间，产生安全问题。

因此，为了能够完成必须的检查，以及在用户空间和内核空间之间安全地传送数据，就需要使用内核提供的函数。比如在sys_hello函数的第6行，就使用了内核提供的strndup_user函数（在mm/util.c文件中定义）从用户空间复制字符串name的内容。

（2）添加系统调用号。

每个系统调用都会拥有一个独一无二的系统调用号，所以接下来需要更新include/asm-i386/unistd.h文件，为hello系统调用添加一个系统调用号。

复制

（3）修改系统调用表。

为了让系统调用处理程序system_call函数能够找到hello系统调用，我们还需要修改系统调用表sys_call_table，放入服务例程sys_hello函数的地址。

复制

新的系统调用hello的服务例程被添加到了sys_call_table的末尾。我们可以注意到，sys_call_table每隔5个表项就会有一个注释，表明该项的系统调用号，这个好习惯可以在查找系统调用对应的系统调用号时提供方便。

（4）重新编译内核并测试。

为了能够使用新添加的系统调用，需要重新编译内核，并使用新内核重新引导系统。然后，我们还需要编写测试程序对新的系统调用进行测试。针对hello系统调用的测试程序如下：

复制

然后使用gcc编译并执行：

复制

由执行结果可见，系统调用添加成功。