linux内核分析学习笔记 ——第五章系统调用的三层机制

学习重点——深入理解系统调用的过程

给MenuOS添加命令

添加命令的方式较为简单，在LinuxKernel/menu/test.c目录下，打开test.c，main函数中的MenuConfig就是对应的系统调用的功能增加，之后在上面给出具体实现即可。之后就可以在MenuOS中使用该系统调用函数。

上面在MenuOS中添加了功能，我这里改成了getuid获得当前用户的id号，调试步骤和实验三基本一样

qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -S -s

冻结内核运行，然后利用gdb调试工具，加载内核，连接端口1234
file linux-3.18.5/vmlinux
target remote:1234

之后在系统调用sys_getuid处设置断点，当启动MenuOS调用功能Getuid后一旦调用系统函数，程序暂停。可以看到程序停在了sys_getuid处，但该系统调用是利用宏函数实现的，经过预编译处理后是sys_getuid的形式。

在system_call位置设置断点并不能停下，还是会停在sys_getuid这里，因为system_call并不是一个正常的函数，只是一段汇编代码的起点，内部没有严格的函数调用堆栈机制，所以gdb不能完成跟踪任务

在用户态中有一个c语言提供的APIxyz()，在用户看来这就是系统调用，而xyz()中调用了SYSCALL来触发系统调用。
即中断向量0x80对应system_call中断服务程序入口。

start_kernel函数执行内核启动的初始化工作，其中会调用trap_init函数，在上图所示目录中可以看到以下代码。

当接受到int 0x80 中断请求后，通过set_sysytem_trap_gate函数将中断向量和入口函数绑定，将直接进入中断，也就是跳转到system_call的位置。

这里将trap_init中绑定中断向量和入口函数的代码中的宏定义实现，可以看到系统调用对应的中断向量就是0x80

system_call是一段中断服务程序入口的汇编代码，就是系统调用的处理过程，是系统调用用户态和系统调用内核态想转换的过程。

中断过程都会有现场保护和恢复现场代码一开始的SAVE_ALL和restore_all就是实现了中断上下文过程。

sys_call_table是一个系统调用表，EAX寄存器保存了传递的系统调用号，来调用相应的系统调用，调用结束，EAX寄存器还要保存系统调用的返回值。

syscall_exit中判断当前的任务是否需要进程调度，如果需要进程调度进入syscall_exit_work，执行进程调度，结束后恢复现场返回用户态。

上图所示是系统调用system_call的流程图

SAVE ALL 是中断发生后保存现场的宏
cmpl $(nr_syscalls),%eax判断检查系统调用号的合法性如果系统调用号大于nr_syscalls 那么出现异常，跳入异常处理syscall_badsys
-call *sys_call_table(,%eax,4)通过系统调用号在系统调用表中找到相应的系统调用内核处理函数，就是将函数API和系统调用联系起来。
movl %eax,PT_EAX(%esp)作用是将系统调用返回值入栈
syscall exit检查是否有任务要处理，如果发生进程调度需要进入syscall_exit_work
- 进程间通信会有信号发生，所以进入进程调度后会有work_pending、work_notifysig信号处理、和work_resched等处理 work_resched中的schedule存着进程调度的代码，也就是进程调度的时机点
restore_all和iret用于恢复现场和返回用户态。