分析system_call中断处理过程
一、先在实验楼的虚拟机中MenuOs增加utsname和utsname-asm指令。
具体实现如下：
1、克隆最新新版本的menu，之后进入menu
2、进入test.c，完成之后make rootfs，使系统自动编译自动运行
3.设置分割点，用gdb追踪
4.设置断点
二、然后开始使用gdb追踪系统调用内核函数sys_time
1、设置断点sys_time
2.继续执行，系统会启动到menuos，执行time命令（可发现此命令执行到一半卡住了），可以看到出现了一个断点
3.继续单步执行，直到出现return i
4.设置断点（system_call），继续执行可发现time有返回
三、系统调用分析
系统调用时用户态进入内核态的唯一入口，常用的系统调用有：
控制硬件：如read/write调用；
设置系统状态或读取内核数据——getpid()、getpriority()、setpriority()、sethostname()；
进程管理：fork()、clone()、execve()、exit()等。
- sys_call代码分析
push1 %eax /*将系统调用号压栈*/
SAVE_ALL
cmp1$(NR_syscalls)，%eax /*检查系统调用号*/
jb nobadsys
mov1 $(-ENOSYS), 24(%esp) /*堆栈中的eax设置为-ENOSYS，作为返回值*/
jmp ret_from_sys_call
nobadsys:
call *sys_call_table(, %eax, 4) #调用系统调用表中调用号为eax的系统调用例程。
mov1 %eax,EAX(%esp) #将返回值存入堆栈中
jmp ret_from_sys_call
分析：
首先将系统调用号（eax）和可以用到的所有CPU寄存器保存到相应的堆栈中（由SAVE_ALL完成）；
对用户态进程传递过来的系统调用号进行有效检查（eax是系统调用号，它应该小于NR_syscalls）,如果是合法的系统调用，再进一步检测该系统调用是否正被跟踪。根据eax中的
系统调用号调用相应的服务例程。
服务例程结束后，从eax寄存器获得它的返回值，并把这个返回值存放在堆栈中，让其位于用户态eax寄存器曾存放的位置。然后跳转到ret_from_sys_call()，终止系统调用程序的
执行。
- save_all代码分析
#define save_all
cld;
push1 %es;
push1 %ds;
push1 %eax;
push1 %ebp;
push1 %edi;
push1 %esi;
push1 %edx;
push1 %ecx;
push1 %ebx;
mov1 $(__KERNEL_DS),%edx;
mov1 %edx, %ds;
mov1 %edx,%es;
分析：
SAVE_ALL将寄存器的参数压入到核心栈中（这样内核才能使用用户传入的参数）。因为子啊不同特权级之间控制转换时，INT指令不同于CALL指令，它不会将外层堆栈的参数
自动拷贝到内层堆栈中。所以在调用系统调用时，必须把参数指定到各个寄存器中。
四、从system_call开始到iret结束之间的整个过程，可以用流程图表示如下：
五、总结
-
在系统调用返回之前，可能会发生进程调度（call_schedule），其中可能还会发生中断上下文的切换和进程上下文的切换；
-
在当前进程的时候，有些信号可能需要处理。
-
内核可以抽象成是很多种不同的中断处理过程的集合