Linux操作系统分析教程6.pptVIP

xlanchen@2007.9.29 Linux Operating Systems Analysis Linux操作系统分析 主讲：陈香兰 助教：贾永泉、毛熠璐 xlanchen@ustc.edu.cn 3606864-83（西区电三421） Autumn 2007 系统调用 xlanchen@2007.9.29 系统调用的意义 操作系统为用户态进程与硬件设备进行交互提供了一组接口——系统调用 把用户从底层的硬件编程中解放出来 极大的提高了系统的安全性 使用户程序具有可移植性 API和系统调用 应用编程接口(application program interface, API)和系统调用是不同的 API只是一个函数定义 系统调用通过软中断向内核发出一个明确的请求 Libc库定义的一些API引用了封装例程(wrapper routine，唯一目的就是发布系统调用) 一般每个系统调用对应一个封装例程 库再用这些封装例程定义出给用户的API 不是每个API都对应一个特定的系统调用。 首先，API可能直接提供用户态的服务(比如一些数学函数) 其次，一个单独的API可能调用几个系统调用 不同的API可能调用了同一个系统调用 返回值 大部分封装例程返回一个整数，其值的含义依赖于相应的系统调用 -1在多数情况下表示内核不能满足进程的请求 Libc中定义的errno变量包含特定的出错码 系统调用程序及服务例程 当用户态进程调用一个系统调用时，CPU切换到内核态并开始执行一个内核函数。 在Linux中是通过执行int $0x80这条汇编语言来执行系统调用的，这条汇编指令产生向量为128的编程异常 传参：内核实现了很多不同的系统调用，进程必须传递一个名为系统调用号的参数来指明需要调用的系统调用，eax寄存器就用作这个目的 所有的系统调用返回一个整数值。这里的返回值与封装例程返回值的约定是不同的。 正数或0表示系统调用成功结束 负数表示一个出错条件，此时这个负值将要存放在errno变量中返回给应用程序。内核没有设置或使用errno变量，封装例程在系统调用返回取得返回值之后设置这个变量 系统调用处理程序也其他异常处理程序的结构类似，执行下列操作 在进程的内核态堆栈中保存大多数寄存器的内容(即保存恢复进程到用户态执行所需要的上下文) 调用名为系统调用服务例程的相应的C函数来处理系统调用 通过ret_from_sys_call()从系统调用返回 应用程序、封装例程、系统调用处理程序及系统调用服务例程之间的关系 为了把系统调用号与相应的服务例程关联起来，内核利用了一个系统调用分派表(dispatch table)。 这个表存放在sys_call_table数组中， 有NR_syscalls个表项(通常是256)：第n个表项 对应了系统调用号为n的服务例程的入口地址的指针 观察sys_call_table 初始化系统调用 内核初始化期间调用trap_init()函数建立IDT表中向量128对应的表项，语句如下： set_system_gate(0x80,$system_call); 该调用把下列值存入这个系统门描述符的相应字段: segment selector 内核代码段__KERNEL_CS的段选择符 offset 指向system_call()异常处理程序的入口地址type 置为15。表示这个异常是一个陷阱，相应的处理程序不禁止可屏蔽中断 DPL(描述符特权级) 置为3。这就允许用户态进程访问这个门，即在用户程序中使用int $0x80是合法的 system_call()函数 参数传递 系统调用也需要输入输出参数，例如 实际的值 用户态进程地址空间的变量的地址 甚至是包含指向用户态函数的指针的数据结构的地址 system_call是linux中所有系统调用的入口点，每个系统调用至少有一个参数，即由eax传递的系统调用号 一个应用程序调用fork()封装例程，那么在执行int $0x80之前就把eax寄存器的值置为2(即__NR_fork)。 这个寄存器的设置是libc库中的封装例程进行的，因此用户一般不关心系统调用号 很多系统调用需要不止一个参数 普通C函数的参数传递是通过把参数值写入堆栈(用户态堆栈或内核态堆栈)来实现的。但因为系统调用是一种特殊函数，它由用户态进入了内核态，所以既不能使用用户态的堆栈也不能直接使用内核态堆栈 在int $0x80汇编指令之前，系统调用的参数被写入CPU的寄存器。然后，在进入内核态调用系统调用服务例程之前，内核再把存放在CPU寄存器中的参数拷贝到内核态堆栈中。因为毕竟服务例程是C函数，它还是要到堆栈中去寻找参数的 回想一下在进入中断和异常处理程序前，在内核态堆栈中保存的pt_regs结