课本：第五章 系统调用的三层机制（下）
- 中断向量0x80和system_call中断服务程序入口的关系
0x80对应着system_call中断服务程序入口，在start_kernel函数中调用了trap_init函数，trap_init函数中调用了set_system_trap_gate函数，其中有系统调用的中断向量0x80和system_call中断服务程序入口的函数指针，system_call被声明为一个函数，通过set_system_trap_gate函数绑定了中断向量0x80和system_call中断服务程序入口之后，一旦执行int 0x80，CPU就直接跳转到system_call这个位置执行。 - 系统调用用户态接口和系统调用的内核处理函数是通过系统调用号匹配起来的
- system_call中断服务程序执行流程
从entry(system_call)开始执行，根据系统调用号来查sys_call_table表中的位置，调用系统调用对应的处理函数，在syscall_exit里面判断当前任务是否需要处理syscall_exit_work，进入syscall_exit_work，这是最常见的进程调度时机点。
其中sys_call_table(,%eax,4)可以理解为，分派表中每个表项占4个字节，所以先把系统调用号（eax）乘以4，再加上sys_call_table分派表的起始地址，得到系统调用号对应的系统调用内核处理函数的指针。
system_call的执行流程图如下图所示：
其中，cmpl部分是检查系统调用号（应小于nr_syscalls），不合法即跳入syscall_badsys异常处理，movl部分是保存返回值到栈中，syscall_exit检查是否有任务需要处理，有则进入syscall_exit_work，无则恢复现场。
实验：分析system_call中断处理过程
上周我进行实验选择的系统调用是38号rename，首先修改menu目录下的test.c文件，添加Rename函数，并在main里menuconfig方法里调用，如下图所示：
在进行make rootfs后，在qemu中的执行效果如下：
后打开gdb，在gdb中调试，在start_kernel和rename的系统调用入口sys_rename两个地方设置断点，执行效果如下图所示：
在menuOS中执行rename指令后，断点停在sys_rename系统调用入口处，如下图所示：
对system_call的流程理解见上部分流程图所示。
总结
本周实验是了解系统调用在内核代码中的处理过程，实验实践起来会比较容易，但真正了解其在内核代码中的处理过程是十分困难的，在gdb环境下有些特殊的汇编代码还无法跟踪调试。使用 ALD(Assembly Language Debugger)这个汇编代码调试器可以完成汇编代码的调试，这会在以后进行实现。总统来说，进行本实验之后对system_call的关键流程有了清晰的了解，具体的细节指令还有待研究。
本周的实验遇到一个路径问题。在LinuxKernel/menu目录下直接执行init可执行文件，在menuOS下执行rename指令，发现指令返回提示成功，并成功更改文件名，如下图所示：
后把文件名更改回原文件名，在qemu环境下启动内核和menuOS，执行rename指令，指令返回error，并未成功更改文件名，如下图所示：
翻看rename函数源代码，判断应该是文件的路径问题，源码中使用的是相对路径，更改文件路径为绝对路径依然不能成功更改文件名。就非常疑惑，qemu环境下运行menuOS默认的相对路径到底在什么位置？
与同学讨论，大多也遇到了这个问题。本来想使用mkdir系统调用指令来生成文件，后在shell中使用find指令查找此文件夹，但是遇到了访问路径权限不足的问题，升级到root权限也无济于事。。。根据多个系统调用指令实验初步猜想，qemu环境没有默认的路径，其直接从内存中读写文件。这只是猜想，还望了解此问题的同学、老师看到此博可以给予指导解答。