《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之间的主要代码

SAVE_ALL：保存现场

syscall_call:调用了系统调用处理函数

restore all：恢复现场（因为系统调用处理函数也算是一种特殊的“中断”）

syscall_exit_work：如3.中所述

INTERRUPT RETURN：也就是iret，系统调用到此结束

4.从system_call到iret的流程图

PART THREE Conclusion

通过本周学习，在系统中增加自己的函数，提高了学习兴趣与动手能力。

system_call到iret之间的主要代码的学习更是让我对于内核有了更加深入的了解