《Linux 内核分析》第五周

【李行之原创作品 转载请注明出处 《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000 】

《Linux内核分析》 第五周

PART ONE 实验过程

1.在MenusOS中增加time和time-asm命令

• 更新menu代码到最新版本（删除当前版本重新下载）；
• 在main函数中增加MenuConfig ;
• 增加对应的time和time－asm函数
• make rootfs（自动编译）
• 实验截图：

（1）在main函数（test.c）中增加函数

（2）运行结果

2.使用gdb跟踪系统调用内核函数sys_time

• 进入内核，冻结启动

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

• 启动gdb
• 加载debug版本内核并连接到target地址
• 为处理time函数的系统调用sys_time设置断点之后，在menuOS中执行time。发现系统停在sys_time处。继续按n单步执行，会进入schedule函数。
• sys_time返回之后进入汇编代码处理，gdb无法继续跟踪
  -如果在sys_call设置断点（entry_32.S），然后输入c之后，发现是不会在sys_call处停下来的（因为这里是一处系统调用函数而不是正常函数）
  -调试过程：
  

PART TWO 系统调用在内核代码中的工作机制和初始化

1.系统调用机制的初始化

trap_gate函数中，涉及到了系统调用的中断向量和system_call的汇编代码入口；一旦执行int 0x80，CPU直接跳转到system_call

2.简化后便于理解的system_call伪代码

• system_call的位置就在ENTRY（system_call）处；（其他中断的处理过程与此类似）
• syscall_table是系统调用表
• after_call之后，保存返回值
• 要exit的时候，会有一个syscall_exit_work，否则直接返回用户态

3.简单浏览system_call到iret之间的主要代码

1. SAVE_ALL：保存现场
2. syscall_call:调用了系统调用处理函数
3. restore all：恢复现场（因为系统调用处理函数也算是一种特殊的“中断”）
4. syscall_exit_work：如3.中所述
5. INTERRUPT RETURN：也就是iret，系统调用到此结束

4.从system_call到iret的流程图

PART THREE Conclusion

• 通过本周学习，在系统中增加自己的函数，提高了学习兴趣与动手能力。
• system_call到iret之间的主要代码的学习更是让我对于内核有了更加深入的了解