【李行之原创作品 转载请注明出处 《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之间的主要代码
- SAVE_ALL:保存现场
- syscall_call:调用了系统调用处理函数
- restore all:恢复现场(因为系统调用处理函数也算是一种特殊的“中断”)
- syscall_exit_work:如3.中所述
- INTERRUPT RETURN:也就是iret,系统调用到此结束
4.从system_call到iret的流程图
PART THREE Conclusion
- 通过本周学习,在系统中增加自己的函数,提高了学习兴趣与动手能力。
- system_call到iret之间的主要代码的学习更是让我对于内核有了更加深入的了解