系统调用1
一、 什么是系统调用
在Linux的世界里，我们经常会遇到系统调用这一术语，所谓系统调用，就是内核提供的、功能十分强大的一系列的函数。这些系统调用是在内核中实现的，再通过一定的方式把系统调用给用户，一般都通过门(gate)陷入(trap)实现。系统调用是用户程序和内核交互的接口。
二、 系统调用的作用
系统调用在Linux系统中发挥着巨大的作用，如果没有系统调用，那么应用程序就失去了内核的支持。
我们在编程时用到的很多函数，如fork、open等这些函数最终都是在系统调用里实现的，比如说我们有这样一个程序：
这里我们用到了两个函数，即fork和exit,这两函数都是glibc中的函数，但是如果我们跟踪函数的执行过程，看看glibc对fork和exit函数的实现就可以发现在glibc的实现代码里都是采用软中断的方式陷入到内核中再通过系统调用实现函数的功能的。具体过程我们在系统调用的实现过程会详细的讲到。
由此可见，系统调用是用户接口在内核中的实现，如果没有系统调用，用户就不能利用内核。
三、 系统调用的现实及调用过程
详细讲述系统调用的之前也讲一下Linux系统的一些保护机制。
Linux系统在CPU的保护模式下提供了四个特权级别，目前内核都只用到了其中的两个特权级别，分别为“特权级0”和“特权级3”,级别0也就是我们通常所讲的内核模式，级别3也就是我们通常所讲的用户模式。划分这两个级别主要是对系统提供保护。内核模式可以执行一些特权指令和进入用户模式，而用户模式则不能。
这里特别提出的是，内核模式与用户模式分别使用自己的堆栈，当发生模式切换的时候同时要进行堆栈的切换。
每个进程都有自己的地址空间（也称为进程空间），进程的地址空间也分为两部分：用户空间和系统空间，在用户模式下只能访问进程的用户空间，在内核模式下则可以访问进程的全部地址空间，这个地址空间里的地址是一个逻辑地址，通过系统段面式的管理机制，访问的实际内存要做二级地址转换，即：逻辑地址?线性地址?物理地址。
系统调用对于内核来说就相当于函数，我们是关键问题是从用户模式到内核模式的转换、堆栈的切换以及参数的传递。
下面将结合内核源代码对这些过程进行分析，以下分析环境为FC2,kernel 2.6.5
下面是内核源代码里arch/i386/kernel/entry.S的一段代码。
以上这段代码里定义了两个非常重要的宏,即SAVE_ALL和RESTORE_ALL
SAVE_ALL先保存用户模式的寄存器和堆栈信息,然后切换到内核模式,宏__SWITCH_KERNELSPACE实现地址空间的转换RESTORE_ALL的过程过SAVE_ALL的过程正好相反
在内核原代码里有一个系统调用表：（entry.S的文件里）
在2.6.5的内核里，有280多个系统调用，这些系统调用的名称全部在这个系统调用表里。
在这个原文件里，还有非常重要的一段。
这一段完成系统调用的执行。
system_call函数根据用户传来的系统调用号，在系统调用表里找到对应的系统调用再执行。
从glibc的函数到系统调用还有一个很重要的环节就是系统调用号。
系统调用号的定义在include/asm-i386/unistd.h里
每一个系统调用号都对应有一个系统调用
接下来就是系统调用宏的展开
没有参数的系统调用的宏展开
！！！代码6::
带一个参数的系统调用的宏展开
！！！代码7::
两个参数
代码8::
#define _syscall2(type,name,type1,arg1,type2,arg2)
三个参数的
代码9::
#define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3)
四个参数的
代码10::
#define _syscall4(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4)
五个参数的
代码11::
#define _syscall5(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4,
type5,arg5)
六个参数的
代码12::
#define _syscall6(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4,
type5,arg5,type6,arg6)
_res);
从这段代码我们可以看出int $0x80通过软中断开触发系统调用，当发生调用时，函数中的name会被系统系统调用名所代替。然后调用前面所讲的system_call。这个过程里包含了系统调用的初始化，系统调用的初始化原代码在：
arch/i386/kernel/traps.c中每当用户执行int 0x80时，系统进行中断处理，把控制权交给内核的system_call。
整个系统调用的过程可以总结如下：
1． 执行用户程序(如:fork)
2． 根据glibc中的函数实现，取得系统调用号并执行int $0x80产生中断
3． 进行地址空间的转换和堆栈的切换，执行SAVE_ALL。（进行内核模式）
4． 进行中断处理，根据系统调用表调用内核函数。
5． 执行内核函数。
6． 执行RESTORE_ALL并返回用户模式
解了系统调用的实现及调用过程，我们可以根据自己的需要来对内核的系统调用作修改或添加。
系统调用楼上说的比较详细了，那我说下库函数和系统调用的区别：
人们在长期编程中发现使用系统调用有个重大的缺点，那就程序的移植性，比如说：linux系统提供的系统调用的函数和windows就不一样，2者不单单是实现的方式不同，提供给用户的函数名，参数都不同，这个可以理解。因此一个实现好的程序，利用了linux的系统调用譬如说wait4函数，那么他在windows上编译是通不过的。于是人们想了个办法，就是封装了windows和linux系统调用，给大家一个统一的函数（我习惯叫它接口),那么这样程序的移植性问题就解决了。
所以可以这么认为库函数是对系统调用的封装（不是所有的库函数都是），为的是解决一些公共的问题和提供统一的系统调用的接口，他和系统调用的优缺点就是：系统调用速度是明显要快于库函数（并不一定全部是，但绝大部分是），但系统调用缺乏移植性。库函数速度要慢，但解决了移植问题。这些在开发过程中要根据自己的实际情况来决定使用那一个。
什么是系统调用？
Linux内核中设置了一组用于实现各种系统功能的子程序，称为系统调用。用户可以通过系统调用命令在自己的应用程序中调用它们。从某种角度来看，系统调用和普通的函数调用非常相似。区别仅仅在于，系统调用由操作系统核心提供，运行于核心态；而普通的函数调用由函数库或用户自己提供，运行于用户态。二者在使用方式上也有相似之处，在下面将会提到。
随Linux核心还提供了一些C语言函数库，这些库对系统调用进行了一些包装和扩展，因为这些库函数与系统调用的关系非常紧密，所以习惯上把这些函数也称为系统调用。
Linux中共有多少个系统调用？
这个问题可不太好回答，就算让Linus Torvaldz本人也不见得一下子就能说清楚。
在2.4.4版内核中，狭义上的系统调用共有221个，你可以在<内核源码目录>/include/asm-i386/unistd.h中找到它们的原本，也可以通过命令"man2 syscalls"察看它们的目录（manpages的版本一般比较老，可能有很多最新的调用都没有包含在内）。广义上的系统调用，也就是以库函数的形式实现的那些，它们的个数从来没有人统计过，这是一件吃力不讨好的活，新内核不断地在推出，每一个新内核中函数数目的变化根本就没有人在乎，至少连内核的修改者本人都不在乎，因为他们从来没有发布过一个此类的声明。
随本文一起有一份经过整理的列表，它不可能非常全面，但常见的系统调用基本都已经包含在内，那里面只有不多的一部分是你平时用得到的，本专栏将会有选择的对它们进行介绍。
为什么要用系统调用？
实际上，很多已经被我们习以为常的C语言标准函数，在Linux平台上的实现都是靠系统调用完成的，所以如果想对系统底层的原理作深入的了解，掌握各种系统调用是初步的要求。进一步，若想成为一名Linux下编程高手，也就是我们常说的Hacker，其标志之一也是能对各种系统调用有透彻的了解。
即使除去上面的原因，在平常的编程中你也会发现，在很多情况下，系统调用是实现你的想法的简洁有效的途径，所以有可能的话应该尽量多掌握一些系统调用，这会对你的程序设计过程带来意想不到的帮助。
系统调用是怎么工作的？
一般的，进程是不能访问内核的。它不能访问内核所占内存空间也不能调用内核函数。CPU硬件决定了这些（这就是为什么它被称作"保护模式"）。系统调用是这些规则的一个例外。其原理是进程先用适当的值填充寄存器，然后调用一个特殊的指令，这个指令会跳到一个事先定义的内核中的一个位置（当然，这个位置是用户进程可读但是不可写的）。在IntelCPU中，这个由中断0x80实现。硬件知道一旦你跳到这个位置，你就不是在限制模式下运行的用户，而是作为操作系统的内核--所以你就可以为所欲为。
进程可以跳转到的内核位置叫做sysem_call。这个过程检查系统调用号，这个号码告诉内核进程请求哪种服务。然后，它查看系统调用表(sys_call_table)找到所调用的内核函数入口地址。接着，就调用函数，等返回后，做一些系统检查，最后返回到进程（或到其他进程，如果这个进程时间用尽）。如果你希望读这段代码，它在<内核源码目录>/kernel/entry.S，Entry(system_call)的下一行。
如何使用系统调用？
先来看一个例子：
#include<linux/unistd.h> /*定义宏_syscall1*/
#include<time.h> /*定义类型time_t*/
_syscall1(time_t,time,time_t *,tloc) /*宏，展开后得到time()函数的原型*/
main()
{
time_t the_time;
the_time=time((time_t *)0); /*调用time系统调用*/
printf("The time is %ld\n",the_time);
}
系统调用time返回从格林尼治时间1970年1月1日0:00开始到现在的秒数。
这是最标准的系统调用的形式，宏_syscall1()展开来得到一个函数原型，稍后我会作详细解释。但事实上，如果把程序改成下面的样子，程序也可以运行得同样的结果。
#include<time.h>
main()
{
time_t the_time;
the_time=time((time_t *)0); /*调用time系统调用*/
printf("The time is %ld\n",the_time);
} |
这是因为在time.h中实际上已经用库函数的形式实现了time这个系统调用，替我们省掉了调用_syscall1宏展开得到函数原型这一步。
大多数系统调用都在各种C语言函数库中有所实现，所以在一般情况下，我们都可以像调用普通的库函数那样调用系统调用，只在极个别的情况下，我们才有机会用到_syscall*()这几个宏。
_syscall*()是什么？
在unistd.h里定义了7个宏，分别是
_syscall0(type,name)
_syscall1(type,name,type1,arg1)
_syscall2(type,name,type1,arg1,type2,arg2)
_syscall3(type,name,type1,arg1,type2,arg2,type3,arg3)
_syscall4(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4)
_syscall5(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4,type5,arg5)
_syscall6(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4,type5,arg5,type6,arg6)
|
它们看起来似乎不太像宏，但其实质和
#define MAXSIZE 100
里面的MAXSIZE没有任何区别。
它们的作用是形成相应的系统调用函数原型，供我们在程序中调用。我们很容易就能发现规律，_syscall后面的数字和typeN,argN的数目一样多。事实上，_syscall后面跟的数字指明了展开后形成函数的参数的个数，让我们看一个实例，就是刚刚用过的time系统调用：
_syscall1(time_t,time,time_t *,tloc) |
展开后的情形是这样：
time_t time(time_t * tloc)
{
long __res;
__asm__ volatile("int $0x80" : "=a" (__res) : "0" (13),"b" ((long)(tloc)));
do {
if ((unsigned long)(__res) >= (unsigned long)(-125)) {
errno = -(__res);
__res = -1;
}
return (time_t) (__res);
} while (0) ;
} |
可以看出，_syscall1(time_t,time,time_t *,tloc)展开成一个名为time的函数，原参数time_t就是函数的返回类型，原参数time_t*和tloc分别构成新函数的参数。事实上，程序中用到的time函数的原型就是它。
errno是什么？
为防止和正常的返回值混淆，系统调用并不直接返回错误码，而是将错误码放入一个名为errno的全局变量中。如果一个系统调用失败，你可以读出errno的值来确定问题所在。
errno不同数值所代表的错误消息定义在errno.h中，你也可以通过命令"man 3 errno"来察看它们。
需要注意的是，errno的值只在函数发生错误时设置，如果函数不发生错误，errno的值就无定义，并不会被置为0。另外，在处理errno前最好先把它的值存入另一个变量，因为在错误处理过程中，即使像printf()这样的函数出错时也会改变errno的值。
系统调用兼容性好吗？
很遗憾，答案是--不好。但这决不意味着你的程序会三天两头的导致系统崩溃，因为系统调用是Linux的内核提供的，所以它们工作起来非常稳定，对于此点无需丝毫怀疑，在绝大多数的情况下，系统调用要比你自己编写的代码可靠而高效的多。
但是，在Linux的各版本内核之间，系统调用的兼容性表现得并不像想象那么好，这是由Linux本身的性质决定的。Linux是一群程序设计高手利用业余时间开发出来的，他们中间的大部分人没有把Linux当成一个严肃的商业软件，（现在的情况有些不同了，随着Linux商业公司和以Linux为生的人的增长，不少人的脑筋发生了变化。）结果就是，如果新的方案在效率和兼容性上发生了矛盾，他们往往舍弃兼容性而追求效率，就这样，如果他们认为某个系统调用实现的比较糟糕，他们就会毫不犹豫的作出修改，有些时候甚至连接口也一起改掉了，更可怕的是，很多时候，他们对自己的修改连个招呼也不打，在任何文档里都找不到关于修改的提示。这样，每当新内核推出的时候，很可能都会悄悄的更新一些系统调用，用户编制的应用程序也会跟着出错。
说到这里，你是不是感觉前途一片昏暗呢？呵呵，不用太紧张，如前面所说，随着越来越多的人把Linux当成自己的饭碗，不兼容的情况也越来越罕见。从2.2版本以后的Linux内核已经非常稳定了，不过尽管如此，你还是有必要在每个新内核推出之后，对自己的应用程序进行兼容性测试，以防止意外的发生。
该如何学习使用Linux系统调用呢？
你可以用"man 2系统调用名称"的命令来查看各条系统调用的介绍，但这首先要求你要有不错的英语基础，其次还得有一定的程序设计和系统编程的功底，manpages不会涉及太多的应用细节，因为它只是一个手册而非教程。如果manpages所提供的东西不能使你感到非常满意，那就跟我来吧，本专栏将向你展示Linux系统调用编程的无穷魅力。
虽然本专栏并非异常高深的技术文章，但是还对读者有两点小小的要求：1)读者必须有一定的C语言编程经验，本专栏不会在语言细节上过分纠缠；2)读者必须有一定的Linux使用经验，本专栏也不打算在Linux应用上大动干戈。举一个小小的测试标准，如果你能完全看懂本文从开头到这里所讲的东西，你就合格了。收拾好行囊，准备出发吧！
附： 《Linux系统调用列表》
参考资料
- Linux man pages
- The Linux Programmer's Guider, Sven Goldt & Sven van der Meer & Scott Burkett & Matt Welsh，1995
- 计算机操作系统，汤子瀛 哲凤屏 汤小丹，西安电子科技大学出版社，2000