系统调用
接口扮演了应用程序和内核进行交互的使者的角色，让应用程序受限的访问硬件设备，确保 了系统的稳定可靠避免应用程序肆意妄行
5.1 与内核通信
系统调用在用户空间和设备之间添加了一个中间层，该层的作用有三个
- 为用户空间提供了一种硬件的抽象接口
- 保证了系统的稳定和安全
- 每个进程都运行在虚拟系统中，而在用户空间和系统的其余部分提供这样一层公共接口也是出于安全稳定性的考虑
在Linux中，系统调用是用户空间访问内核的唯一手段，除异常和中断外，他们是内核的唯一合法入口
5.2 API、POSIX和C库
一般情况下，应用程序通过用户空间实现的应用编程接口而不是直接通过系统调用来编程
POSIX
最流行的应用程序接口是基于POSIX标准的，其目标是提供一套大体上基于Unix的可一直操作系统标准
Linux的系统调用作为C库的一部分提供，实现了Unix系统的主要API
从程序员的角度来看，系统调用无关紧要，他们只需要跟API打交道，而对内核来说，只跟系统调用打交道
5.3 系统调用
要访问系统调用，通常通过C库中定义的函数来进行
5.3.1 系统调用号
在Linux中每个系统调用被赋予一个系统调用号，这样通过一个独一无二的号就可以关联系统调用
系统调用号一旦分配就不能再有任何改变，此外如果一个系统调用被删除，他所占的系统调用号也不允许被回收利用
错误号：未实现系统调用sys_ni_syscall()，只返回—ENOSYS，专门针对无效的系统调用号设计的
5.3.2 系统调用的性能
Linux系统调用比其他许多操作系统执行的要快，Linux很短的上下文切换时间是一个很重要的原因，进出内核被优化的简洁高效。另一个原因就是系统调用处理程序和每个系统调用本身也都非常简洁
5.4 系统调用处理程序
用户空间的程序无法直接执行内核程序的代码。
通知内核的机制是靠中断实现的：通过引发一个异常来促使系统切换到内核态去执行一次处理程序，此时的异常处理程序就是系统调用处理程序
5.4.1 指定恰当的系统调用
在x86上系统调用号是通过eax寄存器来传递给内存的。
system_call()函数通过将给定的系统调用号与NR_systems做比较来检查其有效性，如果大于等于就返回-ENOSYS，否则执行相应的系统调用：
call *sys_call_table(,%rax,8)
5.4.2参数传递
外部参数的传入在发生陷入到饿时候从用户空间传给内核，想传递系统调用号一样，把参数存放在寄存器里。给用户空间的返回值也通过寄存器传递
5.5 系统调用的实现
5.5.1 实现系统调用
实现一个系统调用的第一步是解决他的用途。系统调用的接口应力求简洁，参数尽可能少，并且很多系统提供了标志参数以确保向前兼容，
标志并不是用来让单个系统调用具有多个不同的行为，而是为了即使增加新的功能和选项也不破幻向后兼容或不需要增加新的系统调用。
设计接口的时候要尽量为将来多做考虑，设计的越通用越好。当设计一个系统调用的时候，要时刻注意可移植性和健壮性，不但要考虑当前，还有为将来做打算
5.5.2 参数验证
系统调用必须仔细检查所有的参数是否合法有效。最重要的一种检查就是检查用户提供的指针是否有效。在接收一个用户空间的指针之前，内核必须保证：
- 指针指向的内存区域属于用户空间，进程决不能哄骗内核区读取内核空间的数据
- 指针指向的内存区域在进程的地址空间里。进程决不能哄骗内核区读取其他进程的数据
- 进程决不能绕过内存访问限制
为了向用户空间写入数据，内核提供了copy_to_user()，他需要三个参数
进程空间中的目的内存地址
内核空间的源地址
需要拷贝的数据长度
为了从用户空间读取数据，内核提供了copy_ from _uesr()
该函数把第二个参数指定的位置上的数据拷贝带第一个参数指定的位置上，拷贝的数据长度由第三个参数决定
最后一项是检查针对是否有合法权限
5.6 系统调用上下文
内核在执行系统调用的时候处于进程上下文，current指针指向当前进程，即引发系统调用的那个进程。在进程上下文中内核可以休眠，并且可以被抢占
5.6.1绑定一个系统调用的最后步骤
注册成为一个正式的系统调用：
- 首先在系统调用表的最后加入一个表项，从0开始
-
对于所支持的各种体系结构系统调用号都必须定义于<asm/unistd.h>中
- 系统调用必须被编译进内核映象
5.6.2从用户空间访问系统调用
通常系统调用靠C库支持，值得庆幸的是Linux本身提供了一组宏，用于直接对系统调用进程访问
举个栗子：open（）
系统调用：
long open(const char*,filename,int flag,int,mode)
直接调用：
define NR_open 5
syscall3(long,open,const char*,filename,int,flag,int,mode)
对于每个宏来说，都有2+2*n个参数。第一个参数对应着系统调用的返回值类型。第二个参数对应着系统调用的名称。在以后是按照系统调用参数的顺序排列每个参数的类型和名称
5.6.3 为什么不通过系统调用的方式实现
采用系统调用作为实现方式的利弊
好处
- 系统调用创建容易且使用方便
- Linux系统调用的性能显而易见
问题
- 需要一个系统调用号，而这需要一个内核在处于官方开发版本的时候由官方分配给你
- 系统调用二笔加入稳定内核后就被固化了，为了避免程序崩溃，他的借口不允许改动
- 需要将系统调用分别注册到每个需要支持的体系结构中去
- 在脚本中不容易调用系统调用，也不能从文件中直接访问系统调用
- 由于需要系统调用号，因此在住内核树之外是很难维护和使用系统调用的
- 仅仅是为了简单的信息交换，系统调用有点小题大做
代替方法
- 想信号量这样的某些接口，可以用文件描述符表示
- 吧增加的信息作为一个文件放在sysfs的合适位置
总结
关于unix的接口设计有一句格言：提供机制而不是策略。换句话说，Unix的系统调用抽象出来用于完成某种确定的目的的函数。之余这些函数怎么用完全不需要内核区关心