《Linux内核设计与实现》第五章读书笔记

第五章——系统调用

重点——Linux系统调用的规则和实现方法。

一、与内核通信

系统调用在用户空间进程和硬件设备之间添加了一个中间层。有三个作用：

1.为用户空间提供了一种硬件的抽象接口；

2.系统调用保证了系统的稳定和安全（内核可以基于权限、用户类型和其他规则对需要进行的访问进行裁决）；

3.系统调用是用户空间访问内核的唯一手段，除异常和陷入之外，它们是内核唯一的合法入口。

二、API、POSIX和C库

1. API

1.应用程序通过用户空间实现的一个用编程接口（API）而不是直接通过系统调用来编程。因为应用程序使用的这种编程接口实际上并不需要和内核提供的系统调用对应。

2.一个API定义了一组应用程序使用的编程接口。它们可以实现成一个系统调用，也可以通过调用多个系统调用来实现，也可以不使用任何系统调用。

3.API可以在各种不同的操作系统上实现，给应用程序提供完全相同的接口。

2. Posix

• 基于POSIX标准的应用编程接口在Unix中最流行。
• POSIX是由IEEE的一组标准组成，其目标是提供一套大体上基于Unix的可移植操作系统标准。

3. C库

• C库实现了Unix系统的主要API，包括标准C库函数和系统调用接口。
• C库提供了POSIX的绝大部分API。

理解：内核只跟系统调用打交道，时刻牢记系统调用所有潜在的用途，并保证良好的通用性和灵活性。而不用去关心函数的使用及应用程序怎样使用系统调用。

三、系统调用

1．要访问系统调用，通常通过C库中定义的函数调用来进行。

2．系统调用最终具有一种明确的操作。

3．如何定义一个系统调用：asmlinkage long sys_getpid(void)

• 首先，注意函数声明中的asmlinkage限定词，这是一个编译指令，通知编译器仅从栈中提取该函数的参数。所有的系统调用都需要这个限定词。
• 其次函数返回long。为了保证32位和64位系统的兼容，系统调用在用户空间和内核空间有不同的返回值类型，在用户空间为int在内核空间为long。
• 最后，注意系统调用get_pid()中的在内核中被定义成sys_getpid()。这是Linux中所有系统调用都应该遵守的命名规则，系统调用bar()在内核中也实现为sys_bar()函数。

4．系统调用号

每个系统调用被赋予一个系统调用号。当用户空间的进程执行一个系统调用的时候，系统调用号就用来指明到底是要执行哪个系统调用。进程不会提及系统调用的名称。

注意：

（1）系统调用号一旦分配就不能再有任何变更，否则编译好的应用程序就会崩溃；

（2）如果一个系统调用被删除，它所占用的系统调用号也不允许被回收利用。

（3）内核记录了系统调用表中的所有已经注册过的系统调用列表（这个表为每一个有效的系统调用制定了唯一的系统调用号），存储在sys_call_table中。x86-64中定义在arch/i386/kernel/syscall_64.c中。

5．系统调用的性能

Linux系统调用执行快，两个原因：

• 有很短的上下文切换时间。
• 系统调用处理程序和每个系统调用本身非常简洁。

四、系统调用处理程序

用户空间的程序无法直接执行内核代码，所以以某种方式通知系统，告知内核自己要系统调用，让系统切换到内核状态。

1．通知内核的机制是靠软中断实现的：

通过引发一个异常来促使系统切换到内核态去执行异常处理程序，此时的异常处理程序实际上就是系统调用处理程序，在×86系统上预定义的软中断是中断号128。通过int￥0X80指令触发该中断，这条指令会触发一个异常导致系统切换到内核态并执行第128号异常处理程序，而该程序正是系统调用处理程序，这个处理程序名字起得很贴切，叫system_call().它与硬件体系结构紧密相关。

2．指定恰当的系统调用

（1）所有的系统调用陷入内核方式都一样，并必须把系统调用号一并传给内核。

（2）在x86上，系统调用号是通过eax寄存器传递给内核的。

（3）system_call()函数通过将给定的系统调用号与NR_syscall比较检查有效性。

（4）执行相应的系统调用：call *sys_call_table(,%rax,8)

3．参数传递

（1）x86-32系统，ebx,ecx,edx,esi,edi按顺序存放前五个参数。

（2）需要6个及以上参数时，应用一个单独的寄存器存放指向所有这些参数在用户空间地址的指针。

（3）给用户空间的返回值也通过寄存器传递。在x86系统上，它存放在eax寄存器中。

五、系统调用的实现

1. 实现系统调用

第一步决定用途，不提倡采用多用途的系统调用；

注意：
  1.系统调用的接口应该力求简洁，参数尽可能少。
  2.很多系统调用提供了标志参数以确保向前兼容。标志并不是用来让单个系统调用具有多个不同的行别如前所述，这是不允许的，而是为了即使增加新的功能和选项，也不破坏向后兼容或不需要增加新的系统调用。
  3.系统调用设计得越通用越好。不要假设这个系统调用现在怎么用将来也一定就是这么用。系统调用的目的可能不变，但它的用法却可能改变。
  4.可移植性和健壮性要好，要确保不对系统调用做错误的假设，否则将来这个调用就可能会崩溃。

2. 参数验证

检查所有参数是否合法有效而且正确。进程不应当让内核去访问那些它无权访问的资源。

最重要的一种检查就是检查用户提供的指针是否有效。在接收一个用户空间的指针之前，内核必须保证：

（1）指针指向的内存区域属于用户空间，进程决不能哄骗内核去读内核空间的数据。

（2）指针指向的内存区域在进程的地址空间里，进程决不能哄骗内核去读其他进程的数据。

（3）如果是读，该内存应被标记为可读；如果是写，该内存应被标记为可写；如果是可执行，该内存被标记为可执行。进程绝不能绕过内存访问权限。

完成检查和在内核空间和用户空间之间数据的来回拷贝的两个方法：

向用户空间写入数据：copy_to_user()：
从用户空间读取数据：copy_from_user()： 

六、系统调用上下文

• 内核在执行系统调用的时候处于进程上下文。

• 在进程上下文中，内核可以休眠并且可以被抢占。

• 当系统调用返回的时候，控制权仍在system_call()中，它最终会负责切换到用户空间，并让用户进程继续执行下去。

1．绑定一个系统调用的最后步骤

当编写完一个系统调用后，把它注册成一个正式的系统调用是件琐碎的工作：

首先，在系统调用表的最后加入一个表项。每种支持该系统调用的硬件体系都必须做这样的工作（大部分的系统调用都针对所有的体系结构）从0开始算起，系统调用在该表中的位置就是它的系统调用号。如第10个系统调用分配到的系统调用号为9）

对于所支持的各种体系结构，系统调用号都必须定义于<asm/unistd.h>中。

系统调用必须被编译进内核映象（不能被编译成模块）。这只要把它放进kernel/下的一个相关文件中就可以了，比如sys.c，它包含了各种各样的系统调用。

2．从用户空间访问系统调用

通常，系统调用靠C库支持。
Linux本身提供了一组宏——_syscalln()，用于直接对系统调用进行访问。会设置好寄存器并调用陷入指令。其中，n的范围：0~6，代表传递给系统调用的参数个数。
对每个宏来说，都有2+2*n个参数。

第一个参数：对应系统调用返回值类型；
第二个参数：系统调用的名称；
再以后是按系统调用参数顺序排列的每个参数的类型和名称。

3．为什么不通过系统调用的方式实现

建立一个系统调用的好处：

• 创建容易、使用方便
• Linux系统调用的高性能

问题：

• 系统调用号需要在内核处于开发版本时官方分配
• 系统调用加入稳定内核后被固化，接口不允许做改动
• 需要将系统调用分别注册到每个需要支持的体系结构中去
• 在脚本中不容易调用系统调用，也不能从文件系统直接访问
• 主内核树之外难以维护和使用

替代方法：

• 某些接口可以用文件描述符表示
• 把增加的信息作为文件放在sysfs的合适位置

七、小结

本章主要学习了系统调用到底是什么，它们与库函数和应用程序接口有怎样的关系；Linux内核如何实现系统调用，以及以及执行系统调用的连锁反应：陷入内核，传递系统调用号和参数，执行正确的系统调用函数，并把返回值带回用户空间。然后，增加一个新的系统调用的一过程也就是系统调用的实现过程。