20135317 + 原创作品转载请注明出处 + 《Linux内核分析》MOOC课程http://mooc.study.163.com/course/USTC-1000029000
一、给MenuOS增加time和time-asm命令
1. 克隆并自动编译MenuOS
rm menu -rf 强制删除原menu文件
git clone http://github.com/mengning/menu.git 从github中克隆
cd menu
make rootfs 运行自动编译脚本，生成根文件系统，启动MenuOS
2. 给MenuOS增加time和time-asm命令
- 更新menu代码到最新版
- test.c中main函数里，增加MenuConfig
- 增加对应的两个函数：Time和TimeAsm
- make rootfs
二、调试内核
1. 使用gdb跟踪调试内核
qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S
------------分隔线------------
gdb
（gdb）file linux-3.18.6/vmlinux //加载符号表
（gdb）target remote:1234 //连接
- b sys_time：在系统调用time的位置设置断点
- c：在MenuOs里使用time，停在断点处
三、系统调用在内核代码中的处理过程
1. 系统调用在内核代码中的工作机制和初始化
- main.c中start_kernel函数：trap_init()
- set_system_trap_gate(SYSCALL_VECTOR,&system_call)
- SYSCALL_VECTOR：系统调用的中断向量
- &system_call：汇编代码入口
- 一执行int 0x80，系统直接跳转到system_call。
2. 系统调用——一个特殊的中断
-
SAVE_ALL：保存现场
-
call *sys_call_table(,%eax,4)调用了系统调度处理函数，eax存的是系统调用号，是实际的系统调度程序。
- sys_call_table：系统调用分派表
-
syscall_after_all：保存返回值
-
若有sys_exit_work，则进入sys_exit_work:会有一个进程调度时机。
- work_pending -> work_notifysig，用来处理信号
- 可能call schedule：进程调度代码
- 可能跳转到restore_all，恢复现场。
- work_pending -> work_notifysig，用来处理信号
-
若无sys_exit_work，就执行restore_all恢复，返回用户态。
-
INTERRUPT_RETURN <=> iret，结束。
- 在系统调用返回之前，可能发生进程调度，进程调度里就会出现进程上下文的切换。
- 进程间通信可能有信号需要处理。
- 可以将内核视为一系列中断指令的集合。
四、实践
1. 使用gdb跟踪分析122号系统调用内核函数：uname
-
先执行rm menu -rf，强制删除原有的menu文件夹，使用git命令更新menu代码至最新版。
-
在test.c中增加我编写的两个函数：Uname()和UnameAsm()
-
在main函数中增加两个函数的MenuConfig命令项：
-
make rootfs编译错误：
- 原因：忘记添加头文件<sys/utsname.h>
-
编译运行，在MenuOS中输入help，可以查看当前所有的系统调用，分别执行uname、uname-asm进行系统调用：
-
插入断点并调试：
2. 从system_call到iret
-
简单流程
五、总结：从系统调用处理过程到一般的中断处理过程
系统调用就是特殊的一种中断
1. 保存现场
- 在系统调用时，我们需要SAVE_ALL，用于保存系统调用时的上下文。
- 同样，中断处理的第一步应该也要保存中断程序现场。
- 目的：在中断处理完之后，可以返回到原来被中断的地方，在原有的运行环境下继续正确的执行下去。
2. 确定中断信息
- 在系统调用时，我们需要将系统调用号通过eax传入，通过
sys_call_table查询到调用的系统调用，然后跳转到相应的程序进行处理。 - 同样，中断处理时系统也需要有一个中断号，通过检索中断向量表，了解中断的类型和设备。
3. 处理中断
- 跳转到相应的中断处理程序后，对中断进行处理。
4. 返回
- 系统调用时最后要restore_all恢复系统调用时的现场，并用iret返回用户态。
- 同样，执行完中断处理程序，内核也要执行特定指令序列，恢复中断时现场，并使得进程回到用户态。
