linux内核系统调用和标准C库函数的关系分析(3） 应用程序, linux, 接口, 空间, 硬件

yuyang911220

5.1.6  为什么需要系统调用
为什么需要系统调用？主要有以下两方面原因。
（1）系统调用可以为用户空间提供访问硬件资源的统一接口，以至于应用程序不必去关注具体的硬件访问操作。比如，读写文件时，应用程序不用去管磁盘类型，甚至于不用关心是哪种文件系统。
（2）系统调用可以对系统进行保护，保证系统的稳定和安全。系统调用的存在规定了用户进程进入内核的具体方式，换句话说，用户访问内核的路径是事先规定好的，只能从规定位置进入内核，而不准许肆意跳入内核。有了这样的进入内核的统一访问路径限制才能保证内核的安全。
我们可以形象地描述这种机制：作为一个游客，你可以买票要求进入野生动物园，但你必须老老实实地坐在观光车上，按照规定的路线观光游览。当然，不准下车，因为那样太危险，不是让你丢掉小命，就是让你吓坏了野生动物。
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系统调用的服务例程原型为：
sys_write(unsigned int fd, const char * buf, size_t count);调用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文件中定义。
asmlinkage long sys_ni_syscall(void) { return -ENOSYS; }sys_ni_syscall的确是最简单的系统调用服务例程，表面上看，它可能并没有什么用处，但是，它在sys_call_table中占据了很多位置。多数位置上的sys_ni_syscal都代表了那些已经被内核中淘汰的系统调用，比如：
.long sys_ni_syscall /* old stty syscall holder */ .long sys_ni_syscall /* old gtty syscall holder */就分别代替了已经废弃的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系统调用的服务例程
asmlinkage long sys_dup(unsigned int fildes) 193 { int ret = -EBADF; struct file * file = fget(fildes); if (file) ret = dupfd(file, 0); return ret; }除了sys_ni_call()以外，sys_dup()称得上是最简单的服务例程之一，但是它却是Linux输入/输出重定向的基础。
在Linux中，执行一个shell命令时通常会自动打开3个标准文件：标准输入文件（stdin），通常对应终端的键盘；标准输出文件（stdout）和 标准错误输出文件（stderr），通常对应终端的屏幕。shell命令从标准输入文件中得到输入数据，将输出数据输出到标准输出文件，而将错误信息输出到标准错误文件中。
比如下面的命令：
  

   
• $cat /proc/cpuinfo

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

   
• $cat
• Hello!
• Hello!

用户输入的每一行都将立刻被输出到屏幕上。
输入重定向是指把命令的标准输入重定向到指定的文件中，即输入可以不来自键盘，而来自一个指定的文件。所以说，输入重定向主要用于改变一个命令的输入源。
输出重定向是指把命令的标准输出或标准错误输出重新定向到指定文件中。这样，该命令的输出就不显示在屏幕上，而是写入到指定文件中。我们经常会利用输出重定向将程序或命令的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文件中，通常都是我们的屏幕上。