分析system_call中断处理过程
符钰婧 原创作品转载请注明出处
《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000
这次的实验是使用gdb跟踪分析一个系统调用内核函数，这里用的是122号函数uname。
先在实验楼的虚拟机中MenuOs增加uname和uname-asm指令。
具体实现如下：
1、克隆新版本的menu
2、进入menu
3、进入test.c
4、添加代码
5、待续。。
接下来分析system_call代码的具体调用过程（代码在kernel/entry_32.S中）
（由于代码较复杂，孟宁老师在视频中讲解了简化之后的伪代码，本文也将用简化代码来分析系统调用的过程）
简化代码如下：
代码中先定义了两个宏（SAVE_ALL、RESTORE_ALL）
16行是调用此系统调用所对应的函数（在122号函数uname中调用的就是sys_newuname）；
17行保存返回值；
在18行exit的时候，会检测当前的任务是不是需要处理；
如果不需要处理，就跳转到21行restore_all；
然后执行23行return，系统调用就结束了。
*但是一般情况下都会有需要处理的任务，此时就会进入到26行处syscall_exit_work
然后跳转到30行work_pending，32行处理信号；
如果需要重新调度，就会执行到33行work_resched，先进行调度call_schedule，然后再跳转到restore_all，返回系统调用。
从system_call开始到iret结束之间的整个过程，可以用流程图表示如下：
总结：
在系统调用返回之前，可能会发生进程调度（call_schedule），其中可能还会发生中断上下文的切换和进程上下文的切换；
在当前进程的时候，有些信号可能需要处理。
内核可以抽象成是很多种不同的中断处理过程的集合。