linux系统调用
目录：
1. Linux系统调用原理
2. 系统调用的实现
3. Linux系统调用分类及列表
4.系统调用、用户编程接口(API)、系统命令和内核函数的关系
5. Linux系统调用实例
1.系统调用原理
系统调用，顾名思义，说的是操作系统提供给用户程序调用的一组“特殊”接口。用户程序可以通过这组“特殊”接口来获得操作系统内核提供的服务，比如用户可以通过文件系统相关的调用请求系统打开文件、关闭文件或读写文件，可以通过时钟相关的系统调用获得系统时间或设置定时器等。
从逻辑上来说，系统调用可被看成是一个内核与用户空间程序交互的接口——它好比一个中间人，把用户进程的请求传达给内核，待内核把请求处理完毕后再将处理结果送回给用户空间。
系统服务之所以需要通过系统调用来提供给用户空间的根本原因是为了对系统进行“保护”，因为我们知道Linux的运行空间分为内核空间与用户空间，它们各自运行在不同的级别中，逻辑上相互隔离。所以用户进程在通常情况下不允许访问内核数据，也无法使用内核函数，它们只能在用户空间操作用户数据，调用用户空间函数。比如我们熟悉的“hello world”程序（执行时）就是标准的用户空间进程，它使用的打印函数printf就属于用户空间函数，打印的字符“hello word”字符串也属于用户空间数据。
但是很多情况下，用户进程需要获得系统服务（调用系统程序），这时就必须利用系统提供给用户的“特殊接口”——系统调用了，它的特殊性主要在于规定了用户进程进入内核的具体位置；换句话说，用户访问内核的路径是事先规定好的，只能从规定位置进入内核，而不准许肆意跳入内核。有了这样的陷入内核的统一访问路径限制才能保证内核安全无虞。我们可以形象地描述这种机制：作为一个游客，你可以买票要求进入野生动物园，但你必须老老实实地坐在观光车上，按照规定的路线观光游览。当然，不准下车，因为那样太危险，不是让你丢掉小命，就是让你吓坏了野生动物。
备注：
- 在一些嵌入式操作系统中，操作系统往往通过API的形式提供给用户一些接口，然后通过静态链接的方式实现对系统的调用，因此这种模式系统态和用户态不明显，即用户可以在其线程中直接调用系统的函数，并没有切换到内核态。
2.系统调用的实现
Linux中实现系统调用利用了0x86体系结构中的软件中断。软件中断和我们常说的中断(硬件中断)不同之处在于，它是通过软件指令触发而并非外设引发的中断，也就是说，又是编程人员开发出的一种异常（该异常为正常的异常），具体的讲就是调用int $0x80汇编指令，这条汇编指令将产生向量为0x80的编程异常。
之所以系统调用需要借助异常来实现，是因为当用户态的进程调用一个系统调用时，CPU便被切换到内核态执行内核函数，而我们在i386体系结构部分已经讲述过了进入内核——进入高特权级别——必须经过系统的门机制，这里的异常实际上就是通过系统门陷入内核（除了int 0x80外用户空间还可以通过int3——向量3、into——向量4 、bound——向量5等异常指令进入内核，而其他异常无法被用户空间程序利用，都是由系统使用的）。
我们更详细地解释一下这个过程。int $0x80指令的目的是产生一个编号为0x80的编程异常，这个编程异常对应的是中断描述符表IDT中的第128项——也就是对应的系统门描述符。门描述符中含有一个预设的内核空间地址，它指向了系统调用处理程序：system_call()（别和系统调用服务程序混淆,这个程序在entry.S文件中用汇编语言编写）。
很显然，所有的系统调用都会统一地转到这个地址，但Linux一共有2、3百个系统调用都从这里进入内核后又该如何派发到它们到各自的服务程序去呢？别发昏，解决这个问题的方法非常简单：首先Linux为每个系统调用都进行了编号（0—NR_syscall），同时在内核中保存了一张系统调用表，该表中保存了系统调用编号和其对应的服务例程，因此在系统调入通过系统门陷入内核前，需要把系统调用号一并传入内核，在x86上，这个传递动作是通过在执行int0x80前把调用号装入eax寄存器实现的。这样系统调用处理程序一旦运行，就可以从eax中得到数据，然后再去系统调用表中寻找相应服务例程了。
除了需要传递系统调用号以外，许多系统调用还需要传递一些参数到内核，比如sys_write(unsigned int fd, const char * buf, size_t count)调用就需要传递文件描述符fd、要写入的内容buf、以及写入字节数count等几个内容到内核。碰到这种情况，Linux会有6个寄存器可被用来传递这些参数：eax (存放系统调用号)、 ebx、ecx、edx、esi及edi来存放这些额外的参数（以字母递增的顺序）。具体做法是在system_call( )中使用SAVE_ALL宏把这些寄存器的值保存在内核态堆栈中.
备注：
- 系统调用其实很简单，就是所以操作系统的API都是通过软件的中断动态的调用，通过调用int $0x80 触发软件中断，然后通过一些寄存器将参数传入，实现对操作系统API的调用。
- 在嵌入式操作系统中有软中断的概念，该软中断是指将硬中断中次优先级的任务交给软中断处理，其运行于系统栈中，优先级高于任务，和本章所提及的软件中断有很大的区别，软件中断处理和硬中断处理流程相同，只是该中断由软件触发。
3.系统调用、用户编程接口（API）、系统命令和内核函数的关系
系统调用并非直接和程序员或系统管理员打交道，它仅仅是一个通过软中断机制（我们后面讲述）向内核提交请求，获取内核服务的接口。而在实际使用中程序员调用的多是用户编程接口——API，而管理员使用的则多是系统命令。
用户编程接口其实是一个函数定义，说明了如何获得一个给定的服务，比如read( )、malloc( )、free( )、abs( )等。它有可能和系统调用形式上一致，比如read()接口就和read系统调用对应，但这种对应并非一一对应，往往会出现几种不同的API内部用到同一个系统调用，比如malloc( )、free( )内部利用brk( )系统调用来扩大或缩小进程的堆；或一个API利用了好几个系统调用组合完成服务。更有些API甚至不需要任何系统调用——因为它并不是必需要使用内核服务，如计算整数绝对值的abs（）接口。
另外要补充的是Linux的用户编程接口遵循了在Unix世界中最流行的应用编程界面标准——POSIX标准，这套标准定义了一系列API。在Linux中（Unix也如此），这些API主要是通过C库（libc）实现的，它除了定义的一些标准的C函数外，一个很重要的任务就是提供了一套封装例程（wrapper routine）将系统调用在用户空间包装后供用户编程使用。
下一个需要解释一下的问题是内核函数和系统调用的关系。大家不要把内核函数想像的过于复杂，其实它们和普通函数很像，只不过在内核实现，因此要满足一些内核编程的要求。系统调用是一层用户进入内核的接口，它本身并非内核函数，进入内核后，不同的系统调用会找到对应到各自的内核函数——换个专业说法就叫：系统调用服务例程。实际上针对请求提供服务的是内核函数而非调用接口。
比如系统调用 getpid实际上就是调用内核函数sys_getpid。
asmlinkage long sys_getpid(void)
{
return current->tpid;
}
Linux系统中存在许多内核函数，有些是内核文件中自己使用的，有些则是可以export出来供内核其他部分共同使用的，具体情况自己决定。
内核公开的内核函数——export出来的——可以使用命令ksyms 或 cat /proc/ksyms来查看。另外，网上还有一本归纳分类内核函数的书叫作《The Linux Kernel API Book》，有兴趣的读者可以去看看。
总而言之，从用户角度向内核看，依次是系统命令、编程接口、系统调用和内核函数。在讲述了系统调用实现后，我们会回过头来看看整个执行路径。
备注：
- 内核函数是操作系统自己使用的一些函数，它不对外展现，不提供给用户使用，因此接口可以变化。
- 用户编程接口API是直接呈现给用户的接口，它可以使用多个系统调用构造出一个API，也可以一个系统调用被多个API使用，同时API也不可以使用系统调用，Linux的API有别于ucos操作系统的API，后者直接调用API函数进行静态连接，系统代码也连接到API中。
- 命令在我看来应该是可执行的程序，它单独将API编译成可执行的文件进行处理。
4. Linux系统调用分类及列表
以下是Linux系统调用的一个列表，包含了大部分常用系统调用和由系统调用派生出的的函数。这可能是你在互联网上所能看到的唯一一篇中文注释的Linux系统调用列表，即使是简单的字母序英文列表，能做到这么完全也是很罕见的。
按照惯例，这个列表以manpages第2节，即系统调用节为蓝本。按照笔者的理解，对其作了大致的分类，同时也作了一些小小的修改，删去了几个仅供内核使用，不允许用户调用的系统调用，对个别本人稍觉不妥的地方作了一些小的修改，并对所有列出的系统调用附上简要注释。
其中有一些函数的作用完全相同，只是参数不同。（可能很多熟悉C++朋友马上就能联想起函数重载，但是别忘了Linux核心是用C语言写的，所以只能取成不同的函数名）。还有一些函数已经过时，被新的更好的函数所代替了（gcc在链接这些函数时会发出警告），但因为兼容的原因还保留着，这些函数我会在前面标上“*”号以示区别。
Linux系统调用很多地方继承了Unix的系统调用，但Linux相比传统Unix的系统调用做了很多扬弃，它省去了许多Unix系统冗余的系统调用，仅仅保留了最基本和最有用的系统调用，所以Linux全部系统调用只有250个左右（而有些操作系统系统调用多达1000个以上）。
系统调用主要分为以下几类：
- 控制硬件——系统调用往往作为硬件资源和用户空间的抽象接口，比如读写文件时用到的write/read调用。
- 设置系统状态或读取内核数据——因为系统调用是用户空间和内核的唯一通讯手段，所以用户设置系统状态，比如开/关某项内核服务（设置某个内核变量），或读取内核数据都必须通过系统调用。比如getpgid、getpriority、setpriority、sethostname
- 进程管理——一系统调用接口是用来保证系统中进程能以多任务在虚拟内存环境下得以运行。比如 fork、clone、execve、exit等
2.1进程控制：
| fork | 创建一个新进程 |
| clone | 按指定条件创建子进程 |
| execve | 运行可执行文件 |
| exit | 中止进程 |
| _exit | 立即中止当前进程 |
| getdtablesize | 进程所能打开的最大文件数 |
| getpgid | 获取指定进程组标识号 |
| setpgid | 设置指定进程组标志号 |
| getpgrp | 获取当前进程组标识号 |
| setpgrp | 设置当前进程组标志号 |
| getpid | 获取进程标识号 |
| getppid | 获取父进程标识号 |
| getpriority | 获取调度优先级 |
| setpriority | 设置调度优先级 |
| modify_ldt | 读写进程的本地描述表 |
| nanosleep | 使进程睡眠指定的时间 |
| nice | 改变分时进程的优先级 |
| pause | 挂起进程，等待信号 |
| personality | 设置进程运行域 |
| prctl | 对进程进行特定操作 |
| ptrace | 进程跟踪 |
| sched_get_priority_max | 取得静态优先级的上限 |
| sched_get_priority_min | 取得静态优先级的下限 |
| sched_getparam | 取得进程的调度参数 |
| sched_getscheduler | 取得指定进程的调度策略 |
| sched_rr_get_interval | 取得按RR算法调度的实时进程的时间片长度 |
| sched_setparam | 设置进程的调度参数 |
| sched_setscheduler | 设置指定进程的调度策略和参数 |
| sched_yield | 进程主动让出处理器,并将自己等候调度队列队尾 |
| vfork | 创建一个子进程，以供执行新程序，常与execve等同时使用 |
| wait | 等待子进程终止 |
| wait3 | 参见wait |
| waitpid | 等待指定子进程终止 |
| wait4 | 参见waitpid |
| capget | 获取进程权限 |
| capset | 设置进程权限 |
| getsid | 获取会晤标识号 |
| setsid | 设置会晤标识号 |
1.2文件操作
| fcntl | 文件控制 |
| open | 打开文件 |
| creat | 创建新文件 |
| close | 关闭文件描述字 |
| read | 读文件 |
| write | 写文件 |
| readv | 从文件读入数据到缓冲数组中 |
| writev | 将缓冲数组里的数据写入文件 |
| pread | 对文件随机读 |
| pwrite | 对文件随机写 |
| lseek | 移动文件指针 |
| _llseek | 在64位地址空间里移动文件指针 |
| dup | 复制已打开的文件描述字 |
| dup2 | 按指定条件复制文件描述字 |
| flock | 文件加/解锁 |
| poll | I/O多路转换 |
| truncate | 截断文件 |
| ftruncate | 参见truncate |
| umask | 设置文件权限掩码 |
| fsync | 把文件在内存中的部分写回磁盘 |
1.3文件系统操作
| access | 确定文件的可存取性 |
| chdir | 改变当前工作目录 |
| fchdir | 参见chdir |
| chmod | 改变文件方式 |
| fchmod | 参见chmod |
| chown | 改变文件的属主或用户组 |
| fchown | 参见chown |
| lchown | 参见chown |
| chroot | 改变根目录 |
| stat | 取文件状态信息 |
| lstat | 参见stat |
| fstat | 参见stat |
| statfs | 取文件系统信息 |
| fstatfs | 参见statfs |
| readdir | 读取目录项 |
| getdents | 读取目录项 |
| mkdir | 创建目录 |
| mknod | 创建索引节点 |
| rmdir | 删除目录 |
| rename | 文件改名 |
| link | 创建链接 |
| symlink | 创建符号链接 |
| unlink | 删除链接 |
| readlink | 读符号链接的值 |
| mount | 安装文件系统 |
| umount | 卸下文件系统 |
| ustat | 取文件系统信息 |
| utime | 改变文件的访问修改时间 |
| utimes | 参见utime |
| quotactl | 控制磁盘配额 |
1.4系统控制
| ioctl | I/O总控制函数 |
| _sysctl | 读/写系统参数 |
| acct | 启用或禁止进程记账 |
| getrlimit | 获取系统资源上限 |
| setrlimit | 设置系统资源上限 |
| getrusage | 获取系统资源使用情况 |
| uselib | 选择要使用的二进制函数库 |
| ioperm | 设置端口I/O权限 |
| iopl | 改变进程I/O权限级别 |
| outb | 低级端口操作 |
| reboot | 重新启动 |
| swapon | 打开交换文件和设备 |
| swapoff | 关闭交换文件和设备 |
| bdflush | 控制bdflush守护进程 |
| sysfs | 取核心支持的文件系统类型 |
| sysinfo | 取得系统信息 |
| adjtimex | 调整系统时钟 |
| alarm | 设置进程的闹钟 |
| getitimer | 获取计时器值 |
| setitimer | 设置计时器值 |
| gettimeofday | 取时间和时区 |
| settimeofday | 设置时间和时区 |
| stime | 设置系统日期和时间 |
| time | 取得系统时间 |
| times | 取进程运行时间 |
| uname | 获取当前UNIX系统的名称、版本和主机等信息 |
| vhangup | 挂起当前终端 |
| nfsservctl | 对NFS守护进程进行控制 |
| vm86 | 进入模拟8086模式 |
| create_module | 创建可装载的模块项 |
| delete_module | 删除可装载的模块项 |
| init_module | 初始化模块 |
| query_module | 查询模块信息 |
| *get_kernel_syms | 取得核心符号,已被query_module代替 |
1.5 内存管理
| brk | 改变数据段空间的分配 |
| sbrk | 参见brk |
| mlock | 内存页面加锁 |
| munlock | 内存页面解锁 |
| mlockall | 调用进程所有内存页面加锁 |
| munlockall | 调用进程所有内存页面解锁 |
| mmap | 映射虚拟内存页 |
| munmap | 去除内存页映射 |
| mremap | 重新映射虚拟内存地址 |
| msync | 将映射内存中的数据写回磁盘 |
| mprotect | 设置内存映像保护 |
| getpagesize | 获取页面大小 |
| sync | 将内存缓冲区数据写回硬盘 |
| cacheflush | 将指定缓冲区中的内容写回磁盘 |
1.6网络管理
| getdomainname | 取域名 |
| setdomainname | 设置域名 |
| gethostid | 获取主机标识号 |
| sethostid | 设置主机标识号 |
| gethostname | 获取本主机名称 |
| sethostname | 设置主机名称 |
| socketcall | socket系统调用 |
| socket | 建立socket |
| bind | 绑定socket到端口 |
| connect | 连接远程主机 |
| accept | 响应socket连接请求 |
| send | 通过socket发送信息 |
| sendto | 发送UDP信息 |
| sendmsg | 参见send |
| recv | 通过socket接收信息 |
| recvfrom | 接收UDP信息 |
| recvmsg | 参见recv |
| listen | 监听socket端口 |
| select | 对多路同步I/O进行轮询 |
| shutdown | 关闭socket上的连接 |
| getsockname | 取得本地socket名字 |
| getpeername | 获取通信对方的socket名字 |
| getsockopt | 取端口设置 |
| setsockopt | 设置端口参数 |
| sendfile | 在文件或端口间传输数据 |
| socketpair | 创建一对已联接的无名socket |
1.7 用户管理
| getuid | 获取用户标识号 |
| setuid | 设置用户标志号 |
| getgid | 获取组标识号 |
| setgid | 设置组标志号 |
| getegid | 获取有效组标识号 |
| setegid | 设置有效组标识号 |
| geteuid | 获取有效用户标识号 |
| seteuid | 设置有效用户标识号 |
| setregid | 分别设置真实和有效的的组标识号 |
| setreuid | 分别设置真实和有效的用户标识号 |
| getresgid | 分别获取真实的,有效的和保存过的组标识号 |
| setresgid | 分别设置真实的,有效的和保存过的组标识号 |
| getresuid | 分别获取真实的,有效的和保存过的用户标识号 |
| setresuid | 分别设置真实的,有效的和保存过的用户标识号 |
| setfsgid | 设置文件系统检查时使用的组标识号 |
| setfsuid | 设置文件系统检查时使用的用户标识号 |
| getgroups | 获取后补组标志清单 |
| setgroups | 设置后补组标志清单 |
| ipc | 进程间通信总控制调用 |
1、信号
| sigaction | 设置对指定信号的处理方法 |
| sigprocmask | 根据参数对信号集中的信号执行阻塞/解除阻塞等操作 |
| sigpending | 为指定的被阻塞信号设置队列 |
| sigsuspend | 挂起进程等待特定信号 |
| signal | 参见signal |
| kill | 向进程或进程组发信号 |
| *sigblock | 向被阻塞信号掩码中添加信号,已被sigprocmask代替 |
| *siggetmask | 取得现有阻塞信号掩码,已被sigprocmask代替 |
| *sigsetmask | 用给定信号掩码替换现有阻塞信号掩码,已被sigprocmask代替 |
| *sigmask | 将给定的信号转化为掩码,已被sigprocmask代替 |
| *sigpause | 作用同sigsuspend,已被sigsuspend代替 |
| sigvec | 为兼容BSD而设的信号处理函数,作用类似sigaction |
| ssetmask | ANSI C的信号处理函数,作用类似sigaction |
2、消息
| msgctl | 消息控制操作 |
| msgget | 获取消息队列 |
| msgsnd | 发消息 |
| msgrcv | 取消息 |
3、管道
| pipe | 创建管道 |
4、信号量
| semctl | 信号量控制 |
| semget | 获取一组信号量 |
| semop | 信号量操作 |
5、共享内存
| shmctl | 控制共享内存 |
| shmget | 获取共享内存 |
| shmat | 连接共享内存 |
| shmdt | 拆卸共享内存 |
5.Linux系统调用实例
在前面的文章中，我们已经了解了父进程和子进程的概念，并已经掌握了系统调用exit的用法，但可能很少有人意识到，在一个进程调用了 exit之后，该进程并非马上就消失掉，而是留下一个称为僵尸进程（Zombie）的数据结构。在Linux进程的5种状态中，僵尸进程是非常特殊的一 种，它已经放弃了几乎所有内存空间，没有任何可执行代码，也不能被调度，仅仅在进程列表中保留一个位置，记载该进程的退出状态等信息供其他进程收集，除此 之外，僵尸进程不再占有任何内存空间。从这点来看，僵尸进程虽然有一个很酷的名字，但它的影响力远远抵不上那些真正的僵尸兄弟，真正的僵尸总能令人感到恐 怖，而僵尸进程却除了留下一些供人凭吊的信息，对系统毫无作用。
也许读者们还对这个新概念比较好奇，那就让我们来看一眼Linux里的僵尸进程究竟长什么样子。
备注：僵尸进程就是被删除了任务，它释放了任务栈空间，不再被任务调用，然而它只占用几十个字节的任务控制块内存空间。
当一个进程已退出，但其父进程还没有调用系统调用wait（稍后介绍）对其进行收集之前的这段时间里，它会一直保持僵尸状态，利用这个特点，我们来写一个简单的小程序：
|
Displaycode代码
|
sleep的作用是让进程休眠指定的秒数，在这60秒内，子进程已经退出，而父进程正忙着睡觉，不可能对它进行收集，这样，我们就能保持子进程60秒的僵尸状态。
编译这个程序：
|
Displaycode代码
|
后台运行程序，以使我们能够执行下一条命令
|
Displaycode代码
|
列一下系统内的进程
|
Displaycode代码
|
看到中间的"Z"了吗？那就是僵尸进程的标志，它表示1578（任务PID）号进程现在就是一个僵尸进程。
我们已经学习了系统调用exit，它的作用是使进程退出，但也仅仅限于将一个正常的进程变成一个僵尸进程，并不能将其完全销毁。僵尸进 程虽然对其他进程几乎没有什么影响，不占用CPU时间，消耗的内存也几乎可以忽略不计，但有它在那里呆着，还是让人觉得心里很不舒服。而且Linux系统 中进程数目是有限制的，在一些特殊的情况下，如果存在太多的僵尸进程，也会影响到新进程的产生。那么，我们该如何来消灭这些僵尸进程呢？
先来了解一下僵尸进程的来由，我们知道，Linux和UNIX总有着剪不断理还乱的亲缘关系，僵尸进程的概念也是从UNIX上继承来 的，而UNIX的先驱们设计这个东西并非是因为闲来无聊想烦烦其他的程序员。僵尸进程中保存着很多对程序员和系统管理员非常重要的信息，首先，这个进程是 怎么死亡的？是正常退出呢，还是出现了错误，还是被其它进程强迫退出的？其次，这个进程占用的总系统CPU时间和总用户CPU时间分别是多少？发生页错误 的数目和收到信号的数目。这些信息都被存储在僵尸进程中，试想如果没有僵尸进程，进程一退出，所有与之相关的信息都立刻归于无形，而此时程序员或系统管理 员需要用到，就只好干瞪眼了。
那么，我们如何收集这些信息，并终结这些僵尸进程呢？就要靠我们下面要讲到的waitpid调用和wait调用。这两者的作用都是收集僵尸进程留下的信息，同时使这个进程彻底消失。下面就对这两个调用分别作详细介绍。
wait系统调用介绍wait的函数原型是：
|
Displaycode代码
|
进程一旦调用了wait，就立即阻塞自己，由wait自动分析是否当前进程的某个子进程已经退出，如果让它找到了这样一个已经变成僵尸 的子进程，wait就会收集这个子进程的信息，并把它彻底销毁后返回；如果没有找到这样一个子进程，wait就会一直阻塞在这里，直到有一个出现为止。
参数status用来保存被收集进程退出时的一些状态，它是一个指向int类型的指针。但如果我们对这个子进程是如何死掉的毫不在意，只想把这个僵尸进程消灭掉，（事实上绝大多数情况下，我们都会这样想），我们就可以设定这个参数为NULL，就象下面这样：
|
Displaycode代码
|
如果成功，wait会返回被收集的子进程的进程ID，如果调用进程没有子进程，调用就会失败，此时wait返回-1，同时errno被置为ECHILD。
下面就让我们用一个例子来实战应用一下wait调用，程序中用到了系统调用fork，如果你对此不大熟悉或已经忘记了，请参考上一篇文章《进程管理相关的系统调用（一）》。
|
Displaycode代码
|
编译并运行:
|
Displaycode代码
|
可以明显注意到，在第2行结果打印出来前有10秒钟的等待时间，这就是我们设定的让子进程睡眠的时间，只有子进程从睡眠中苏醒过来，它 才能正常退出，也就才能被父进程捕捉到。其实这里我们不管设定子进程睡眠的时间有多长，父进程都会一直等待下去，读者如果有兴趣的话，可以试着自己修改一 下这个数值，看看会出现怎样的结果。
如果参数status的值不是NULL，wait就会把子进程退出时的状态取出并存入其中，这是一个整数值（int），指出了子进程是 正常退出还是被非正常结束的（一个进程也可以被其他进程用信号结束，我们将在以后的文章中介绍），以及正常结束时的返回值，或被哪一个信号结束的等信息。 由于这些信息被存放在一个整数的不同二进制位中，所以用常规的方法读取会非常麻烦，人们就设计了一套专门的宏（macro）来完成这项工作，下面我们来学 习一下其中最常用的两个：
1，WIFEXITED(status) 这个宏用来指出子进程是否为正常退出的，如果是，它会返回一个非零值。
（请注意，虽然名字一样，这里的参数status并不同于wait唯一的参数--指向整数的指针status，而是那个指针所指向的整数，切记不要搞混了。）
2，WEXITSTATUS(status) 当WIFEXITED返回非零值时，我们可以用这个宏来提取子进程的返回值，如果子进程调用exit(5)退出，WEXITSTATUS(status) 就会返回5；如果子进程调用exit(7)，WEXITSTATUS(status)就会返回7。请注意，如果进程不是正常退出的，也就是 说，WIFEXITED返回0，这个值就毫无意义。
下面通过例子来实战一下我们刚刚学到的内容：
|
Displaycode代码
|
编译并运行:
|
Displaycode代码
|
父进程准确捕捉到了子进程的返回值3，并把它打印了出来。
当然，处理进程退出状态的宏并不止这两个，但它们当中的绝大部分在平时的编程中很少用到，就也不在这里浪费篇幅介绍了，有兴趣的读者可以自己参阅Linux man pages去了解它们的用法。
有时候，父进程要求子进程的运算结果进行下一步的运算，或者子进程的功能是为父进程提供了下一步执行的先决条件（如：子进程建立文件， 而父进程写入数据），此时父进程就必须在某一个位置停下来，等待子进程运行结束，而如果父进程不等待而直接执行下去的话，可以想见，会出现极大的混乱。这 种情况称为进程之间的同步，更准确地说，这是进程同步的一种特例。进程同步就是要协调好2个以上的进程，使之以安排好地次序依次执行。解决进程同步问题有 更通用的方法，我们将在以后介绍，但对于我们假设的这种情况，则完全可以用wait系统调用简单的予以解决。请看下面这段程序：
|
Displaycode代码
|
这段程序只是个例子，不能真正拿来执行，但它却说明了一些问题，首先，当fork调用成功后，父子进程各做各的事情，但当父进程的工作 告一段落，需要用到子进程的结果时，它就停下来调用wait，一直等到子进程运行结束，然后利用子进程的结果继续执行，这样就圆满地解决了我们提出的进程 同步问题。
waitpid系统调用在Linux函数库中的原型是：
|
Displaycode代码
|
从本质上讲，系统调用waitpid和wait的作用是完全相同的，但waitpid多出了两个可由用户控制的参数pid和options，从而为我们编程提供了另一种更灵活的方式。下面我们就来详细介绍一下这两个参数：
从参数的名字pid和类型pid_t中就可以看出，这里需要的是一个进程ID。但当pid取不同的值时，在这里有不同的意义。
- pid>0时，只等待进程ID等于pid的子进程，不管其它已经有多少子进程运行结束退出了，只要指定的子进程还没有结束，waitpid就会一直等下去。
- pid=-1时，等待任何一个子进程退出，没有任何限制，此时waitpid和wait的作用一模一样。
- pid=0时，等待同一个进程组中的任何子进程，如果子进程已经加入了别的进程组，waitpid不会对它做任何理睬。
- pid<-1时，等待一个指定进程组中的任何子进程，这个进程组的ID等于pid的绝对值。
options提供了一些额外的选项来控制waitpid，目前在Linux中只支持WNOHANG和WUNTRACED两个选项，这是两个常数，可以用"|"运算符把它们连接起来使用，比如：
|
Displaycode代码
|
如果我们不想使用它们，也可以把options设为0，如：
|
Displaycode代码
|
如果使用了WNOHANG参数调用waitpid，即使没有子进程退出，它也会立即返回，不会像wait那样永远等下去。
而WUNTRACED参数，由于涉及到一些跟踪调试方面的知识，加之极少用到，这里就不多费笔墨了，有兴趣的读者可以自行查阅相关材料。
看到这里，聪明的读者可能已经看出端倪了--wait不就是经过包装的waitpid吗？没错，察看<内核源码目录>/include/unistd.h文件349-352行就会发现以下程序段：
|
Displaycode代码
|
waitpid的返回值比wait稍微复杂一些，一共有3种情况：
- 当正常返回的时候，waitpid返回收集到的子进程的进程ID；
- 如果设置了选项WNOHANG，而调用中waitpid发现没有已退出的子进程可收集，则返回0；
- 如果调用中出错，则返回-1，这时errno会被设置成相应的值以指示错误所在；
当pid所指示的子进程不存在，或此进程存在，但不是调用进程的子进程，waitpid就会出错返回，这时errno被设置为ECHILD；
|
Displaycode代码
|
编译并运行：
|
Displaycode代码
|
父进程经过10次失败的尝试之后，终于收集到了退出的子进程。
因为这只是一个例子程序，不便写得太复杂，所以我们就让父进程和子进程分别睡眠了10秒钟和1秒钟，代表它们分别作了10秒钟和1秒钟的工作。父子进程都有工作要做，父进程利用工作的简短间歇察看子进程的是否退出，如退出就收集它。
也许有不少读者从本系列文章一推出就开始读，一直到这里还有一个很大的疑惑：既然所有新进程都是由fork产生的，而且由fork产生 的子进程和父进程几乎完全一样，那岂不是意味着系统中所有的进程都应该一模一样了吗？而且，就我们的常识来说，当我们执行一个程序的时候，新产生的进程的 内容应就是程序的内容才对。是我们理解错了吗？显然不是，要解决这些疑惑，就必须提到我们下面要介绍的exec系统调用。
说是exec系统调用，实际上在Linux中，并不存在一个exec()的函数形式，exec指的是一组函数，一共有6个，分别是：
|
Displaycode代码
|
其中只有execve是真正意义上的系统调用，其它都是在此基础上经过包装的库函数。
exec函数族的作用是根据指定的文件名找到可执行文件，并用它来取代调用进程的内容，换句话说，就是在调用进程内部执行一个可执行文件。这里的可执行文件既可以是二进制文件，也可以是任何Linux下可执行的脚本文件。
与一般情况不同，exec函数族的函数执行成功后不会返回，因为调用进程的实体，包括代码段，数据段和堆栈等都已经被新的内容取代，只 留下进程ID等一些表面上的信息仍保持原样，颇有些神似"三十六计"中的"金蝉脱壳"。看上去还是旧的躯壳，却已经注入了新的灵魂。只有调用失败了，它们 才会返回一个-1，从原程序的调用点接着往下执行。
现在我们应该明白了，Linux下是如何执行新程序的，每当有进程认为自己不能为系统和拥护做出任何贡献了，他就可以发挥最后一点余 热，调用任何一个exec，让自己以新的面貌重生；或者，更普遍的情况是，如果一个进程想执行另一个程序，它就可以fork出一个新进程，然后调用任何一 个exec，这样看起来就好像通过执行应用程序而产生了一个新进程一样。
事实上第二种情况被应用得如此普遍，以至于Linux专门为其作了优化，我们已经知道，fork会将调用进程的所有内容原封不动的拷贝 到新产生的子进程中去，这些拷贝的动作很消耗时间，而如果fork完之后我们马上就调用exec，这些辛辛苦苦拷贝来的东西又会被立刻抹掉，这看起来非常 不划算，于是人们设计了一种"写时拷贝（copy-on-write）"技术，使得fork结束后并不立刻复制父进程的内容，而是到了真正实用的时候才复 制，这样如果下一条语句是exec，它就不会白白作无用功了，也就提高了效率。
上面6条函数看起来似乎很复杂，但实际上无论是作用还是用法都非常相似，只有很微小的差别。在学习它们之前，先来了解一下我们习以为常的main函数。
下面这个main函数的形式可能有些出乎我们的意料：
|
Displaycode代码
|
它可能与绝大多数教科书上描述的都不一样，但实际上，这才是main函数真正完整的形式。
参数argc指出了运行该程序时命令行参数的个数，数组argv存放了所有的命令行参数，数组envp存放了所有的环境变量。环境变量 指的是一组值，从用户登录后就一直存在，很多应用程序需要依靠它来确定系统的一些细节，我们最常见的环境变量是PATH，它指出了应到哪里去搜索应用程 序，如/bin；HOME也是比较常见的环境变量，它指出了我们在系统中的个人目录。环境变量一般以字符串"XXX=xxx"的形式存在，XXX表示变量 名，xxx表示变量的值。
值得一提的是，argv数组和envp数组存放的都是指向字符串的指针，这两个数组都以一个NULL元素表示数组的结尾。
我们可以通过以下这个程序来观看传到argc、argv和envp里的都是什么东西：
|
Displaycode代码
|
编译它：
|
Displaycode代码
|
运行时，我们故意加几个没有任何作用的命令行参数：
|
Displaycode代码
|
我们看到，程序将"./main"作为第1个命令行参数，所以我们一共有3个命令行参数。这可能与大家平时习惯的说法有些不同，小心不要搞错了。
现在回过头来看一下exec函数族，先把注意力集中在execve上：
|
Displaycode代码
|
对比一下main函数的完整形式，看出问题了吗？是的，这两个函数里的argv和envp是完全一一对应的关系。execve第1个参 数path是被执行应用程序的完整路径，第2个参数argv就是传给被执行应用程序的命令行参数，第3个参数envp是传给被执行应用程序的环境变量。
留心看一下这6个函数还可以发现，前3个函数都是以execl开头的，后3个都是以execv开头的，它们的区别在于，execv开头 的函数是以"char *argv[]"这样的形式传递命令行参数，而execl开头的函数采用了我们更容易习惯的方式，把参数一个一个列出来，然后以一个NULL表示结束。这 里的NULL的作用和argv数组里的NULL作用是一样的。
在全部6个函数中，只有execle和execve使用了char *envp[]传递环境变量，其它的4个函数都没有这个参数，这并不意味着它们不传递环境变量，这4个函数将把默认的环境变量不做任何修改地传给被执行的 应用程序。而execle和execve会用指定的环境变量去替代默认的那些。
还有2个以p结尾的函数execlp和execvp，咋看起来，它们和execl与execv的差别很小，事实也确是如此，除 execlp和execvp之外的4个函数都要求，它们的第1个参数path必须是一个完整的路径，如"/bin/ls"；而execlp和execvp 的第1个参数file可以简单到仅仅是一个文件名，如"ls"，这两个函数可以自动到环境变量PATH制定的目录里去寻找。
知识介绍得差不多了，接下来我们看看实际的应用：
|
Displaycode代码
|
程序里调用了2个Linux常用的系统命令，echo和env。echo会把后面跟的命令行参数原封不动的打印出来，env用来列出所有环境变量。
由于各个子进程执行的顺序无法控制，所以有可能出现一个比较混乱的输出--各子进程打印的结果交杂在一起，而不是严格按照程序中列出的次序。
编译并运行：
|
Displaycode代码
|
果然不出所料，execle输出的结果跑到了execlp前面。
大家在平时的编程中，如果用到了exec函数族，一定记得要加错误判断语句。因为与其他系统调用比起来，exec很容易受伤，被执行文件的位置，权限等很多因素都能导致该调用的失败。最常见的错误是：
- 找不到文件或路径，此时errno被设置为ENOENT；
- 数组argv和envp忘记用NULL结束，此时errno被设置为EFAULT；
- 没有对要执行文件的运行权限，此时errno被设置为EACCES。
下面就让我用一些形象的比喻，来对进程短暂的一生作一个小小的总结：
随着一句fork，一个新进程呱呱落地，但它这时只是老进程的一个克隆。
然后随着exec，新进程脱胎换骨，离家独立，开始了为人民服务的职业生涯。
人有生老病死，进程也一样，它可以是自然死亡，即运行到main函数的最后一个"}"，从容地离我们而去；也可以是自杀，自杀有2种方 式，一种是调用exit函数，一种是在main函数内使用return，无论哪一种方式，它都可以留下遗书，放在返回值里保留下来；它还甚至能可被谋杀， 被其它进程通过另外一些方式结束他的生命。
进程死掉以后，会留下一具僵尸，wait和waitpid充当了殓尸工，把僵尸推去火化，使其最终归于无形。
这就是进程完整的一生。
本文重点介绍了系统调用wait、waitpid和exec函数族，对与进程管理相关的系统调用的介绍就在这里告一段落，在下一篇文章，也是与进程管理相关的系统调用的最后一篇文章中，我们会通过两个很酷的实际例子，来重温一下最近学过的知识.
浙公网安备 33010602011771号