Linux内核设计与实现第四周读书笔记

第5章系统调用

5.1与内核通信

主要作用：

• 为用户控件提供了一种硬件的抽象接口。
• 保证了系统稳定性与安全性。
• 为用户空间&系统提供公共接口。

5.2API、POSIX和C库

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

总之，Unix系统调用提供机制而不提供策略。换句话说，Unix的系统调用抽象出了用于完成某种确定的目标的函数。

5.3系统调用

• asmlinkage（限定词）：编译指令，通知编译器仅从栈中提取该函数的参数。
• sys_xxxx()：系统调用的函数名前加上sys_，都应遵守的命名规则。

5.3.1系统调用号

一旦分配就不能再有任何变更，否则编译好的应用程序就会崩溃。此外，如果一个系统调用被删除，它所占用的系统调用号也不允许备被回收利用。

内核记录了系统调用表中的所有已注册过的系统调用列表，存储在sys_call_table中。

5.3.2系统调用的性能

快

原因：进程上下文切换快；系统调用处理程序&系统调用简洁

5.4系统调用处理程序

用户空间的程序无法直接执行内核代码。

通知内核的机制是靠软中断实现的：通过引发一个异常来促使系统切换到内核态来执行异常处理程序。此时的异常处理程序实际上就是系统调用处理程序。（int$0x80）

5.4.1指定恰当的系统调用

在陷入内核之前，用户空间就把相应系统调用所对应的号放入eax中。

5.4.2参数传递

参数用寄存器传递。

5.5系统调用实现

Linux系统调用实现时并不徐璈太关心它与系统调用处理程序之间的关系，难在设计和实现。

5.5.1实现系统调用

• 决定它的用途，每个为系统调用都应该有一个明确的用途。
• 新系统调用的参数、返回值和错误码又该是什么呢？接口应该力求简洁，参数尽可能少。
• 系统调用设计得越通用越好。

5.5.2参数验证

系统调用必须仔细检查它们所有的参数是否合法有效。

1检查用户提供的指针是否有效

• 指针指向的内存区域属于用户空间。
• 指针指向的内存区域在进程的地址空间里。
• 如果是读，则内存应被标记为可读。进程决不能绕过内存访问限制。

2检查针对是否有合法权限

5.6系统调用上下文

• 内核在执行系统调用时处于进程上下文。current指针指向当前任务，即引发系统调用的那个进程。
• 在进程上下文中，内核可以休眠并且可以被抢占。
• 当系统调用返回的时候，控制权仍在system_call()中，它负责切换到用户空间，并让用户进程继续执行下去。

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

当编写完一个系统调用后，把它注册成一个正式的系统调用：

• 在系统调用表的最后中加入一个表项。
• 对于所支持的各种体系结构，系统调用号都必须定义于<asm/unistd.h>中。
• 系统调用必须被编译进内核映象（不能被编译成模块）。
• 最后，用户空间就可以调用系统调用函数了。

5.6.2从用户空间访问调用

• 通常系统调用靠C库支持。
• Linux本身提供了一组宏，用于直接对系统调用进行访问。

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

建立一个新的系统调用非常容易，但却绝不提倡这么做。