《Linux内核设计与实现》第四周读书笔记——第五章
《Linux内核设计与实现》第四周读书笔记——第五章
内核提供了用户进程与内核进行交互的一组接口。这些接口让应用程序受限地访问硬件设备，提供了创建进程并与已有进程进行通信的机制，也提供了申请操作系统其它资源的能力。
5.1 与内核通信
系统调用在用户空间进程和硬件设备之间添加了一个中间层，该层主要作用有三个：
- 它为用户空间提供了一种硬件的抽象接口，举例来说当需要读写文件的时候，应用程序就可以不去管磁盘类型和介质，甚至不用去管文件所在的文件系统到底是哪种类型。
- 系统调用保证了系统的稳定和安全，作为硬件设备和应用程序之间的中间人，内核可以基于权限、用户类型和其他一些规则对需要进行的访问进行裁决，举例来说，这样可以避免应用程序不正确地使用硬件设备，窃取其他进程的资源，或做出其他危害系统的事情。
- 在第3章中曾经提到过，每个进程都运行在虚拟系统中，而在用户空间和系统的其余部分提供这样一层公共接口，也是出于这种考虑，如果应用程序可以随意访问硬件而内核又对此一无所知的话几乎就没法实现多任务和虚拟内存，当然也不可能实现良好的稳定性和安全性。
注：在Linux中，系统调用是用户空间访问。内核的唯一手段；除异常和陷入外，它们是内核唯一的合法入口。
5.2 API、POSIX和C库
应用程序通过在用户空间实现的应用编程接口（API）而非直接通过系统调用来编程。
POSIX是应用编程接口的一个国际标准，C库提供了POSIX的绝大部分API。
Unix接口设计的特点：提供机制（需要实现什么功能）而非策略（怎样实现这些功能）。Unix系统调用抽象出了用于完成某种确定的目的的函数，而至于函数是如何实现功能的则并不关心，从程序员的角度来看，只需通过接口便可实现功能。
5.3 系统调用
- 要访问系统调用，通常通过C库中定义的函数调用来进行。
- 系统调用最终具有一种明确的操作。
- 如何定义系统调用
首先，注意函数声明中的asmlinkage限定词，这是一个编译指令，通知编译器仅从栈中提取该函数的参数。所有的系统调用都需要这个限定词。
其次函数返回long。为了保证32位和64位系统的兼容，系统调用在用户空间和内核空间有不同的返回值类型，在用户空间为int在内核空间为long。
最后，注意系统调用get_pid()中的在内核中被定义成sys_getpid()。这是Linux中所有系统调用都应该遵守的命名规则，系统调用bar()在内核中也实现为sys_bar()函数。
5.3.1 系统调用号
-
在Linux系统中每个系统调用被赋予一个系统调用号，当用户空间的进程执行一个系统调用时，系统调用号用来指明执行哪个系统调用
系统调用号一旦分配就不会再更改，被删除的系统调用号也不许再回收。
sys _ ni _ syscall()专门针对无效的系统调用而设立的，只负责返回-ENOSYS。
系统调用号被定义在arch/i386/kernel/syscall_64.c文件中。
5.3.2 系统调用的性能
Linux系统执行快的原因：
- 很短的上下文切换时间。
- 系统调用处理程序和每个系统调用本身也十分简洁。
5.4 系统调用处理程序
用户空间的程序无法执行内核代码。
通知内核的机制是靠软中断实现的：
通过引发一个异常来促使系统切换到内核态去执行异常处理程序，此时的异常处理程序实际上就是系统调用处理程序，在×86系统上预定义的软中断是中断号128。通过int￥0X80指令触发该中断，这条指令会触发一个异常导致系统切换到内核态并执行第128号异常处理程序，而该程序正是系统调用处理程序，这个处理程序名字起得很贴切，叫system_call().它与硬件体系结构紧密相关。
5.4.1 指定恰当的系统调用
- 必须把系统调用号一并传给内核。
- 在x86上，系统调用号是通过eax寄存器传递给内核的。
5.4.2 参数传递
- 除了系统调用号外，大部分系统调用都还需要一些外部的参数输入。
- 最简单的办法是像传递系统调用号一样，把这些参数也放在寄存器里。
- 图2
- 给用户空间的返回值也通过寄存器传递。在x86系统上，它存放在eax寄存器中。
5.5 系统调用的实现
注意可移植性和健壮性。
验证参数是否合法有效：
- 检查用户提供的指针是否有效
- 在用户空间读写数据时检查是否会引起堵塞
- 检查针对是否有合法权限
5.5.1 实现系统调用
- 在Linux中不提倡采用多用途的系统调用。
- 新系统调用的参数、返回值和错误码又该是什么呢？系统调用的接口应该力求简洁，参数尽可能少。系统调用的语义和行为非常关键；因为应用程序依赖于它们，所以它们应力求稳定，不做改动设想一下，如果功能多次改变会怎样。
- 新的功能是否可以追加到系统调用亦或是否某个改变将需要一个全新的函数是否可以容易地修订错误而不用破坏向后兼容？很多系统调用提供了标志参数以确保向前兼容。标志并不是用来让单个系统调用具有多个不同的行别如前所述，这是不允许的，而是为了即使增加新的功能和选项，也不破坏向后兼容或不需要增加新的系统调用。
- 设计接口的时候要尽量为将来多做考虑。你是不是对函数做了不必要的限制？系统调用设计得越通用越好。不要假设这个系统调用现在怎么用将来也一定就是这么用。系统调用的目的可能不变，但它的用法却可能改变。
- 这个系统调用可移植吗？别对机器的字节长度和字节序做假设。要确保不对系统调用做错误的假设否则将来这个调用就可能会崩溃。
5.5.2 参数验证
- 系统调用必须仔细检查它们所有的参数是否合法有效。系统调用在内核空间执行，如果任由用户将不合法的输入传递给内核，那么系统的安全和稳定将面临极大的考验；举例来说，与文件I/O相关的系统调用必须检查文件描述符是否有效。与进程相关的函数必须检查提供的PID是否有效。必须检查每个参数，保证它们不但合法有效，而且正确。进程不应当让内核去访问那些它无权访问的资源。
- 最重要的一种检查就是检查用户提供的指针是否有效。试想，如果一个进程可以给内核传递指针而又无须检查，那么它就可以给出一个它根本就没有访问权限的指针，哄骗内核去为它拷贝本不允许它访问的数据如原本属于其他进程的数据或者不可读的映射数据。在接收一个用户空间的指针之前，内核必须保证：
1.指针指向的内存区域属于用户空间，进程决不能哄骗内核去读内核空间的数据。
2.指针指向的内存区域在进程的地址空间里，进程决不能哄骗内核去读其他进程的数据。
3.如果是读，该内存应被标记为可读；如果是写，该内存应被标记为可写；如果是可执行，该内存被标记为可执行。进程绝不能绕过内存访问权限。
5.6 系统调用上下文
内核在执行系统调用时处于进程上下文。Current指针指向当前任务，即引发系统调用的那个进程。
在进程上下文中，内核可以休眠并且可以被抢占。当系统调用返回的时候，控制权仍在system_call()中，它最终会负责切换到用户空间，并让用户进程继续执行下去。
绑定一个系统调用的最后步
当编写完一个系统调用后，把它注册成一个正式的系统调用是件琐碎的工作：
1.首先，在系统调用表的最后加入一个表项。每种支持该系统调用的硬件体系都必须做这样的工作（大部分的系统调用都针对所有的体系结构）从0开始算起，系统调用在该表中的位置就是它的系统调用号。如第10个系统调用分配到的系统调用号为9）
2.对于所支持的各种体系结构，系统调用号都必须定义于<asm/unistd.h>中。
3.系统调用必须被编译进内核映象（不能被编译成模块）。这只要把它放进kernel/下的一个相关文件中就可以了，比如sys.c，它包含了各种各样的系统调用。
从用户空间访问系统调用
- 通常，系统调用靠C库支持。
- Linux本身提供了一组宏。
