2019-2020-1 20199324《Linux内核原理与分析》第六周作业

第五章 系统调用的三层机制（下）

1.给MenuOS增加命令

进入Linuxkernel目录下，强制删除当前menu目录，再重新克隆一个新版本的menu

进入menu，运行make roofts脚本就可以自动编译并且自动生成根文件系统，还可以运行MenuOS系统。

输入help命令可以发现，当前支持的命令比之前多了。增加了两个命令：time，功能是显示系统时间，还有一个是time_asm，功能是使用汇编的方式来显示时间。

下面来增加一个hello的命令，输出“hello 你的学号”。

打开test.c文件：

给MenuOS增加新的命令只需要使用MenuConfig命令即可。在main()函数中增加一行代码。增加对应的函数如下：

使用make roofts自动编译，输入help命令可以发现，比之前多了一个hello命令。

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

启动内核

再打开一个窗口，水平分割，启动gdb，把内核加载进来建立连接

连接到target remote 1234

在 start_kernel 处设置断点，在gdb中按c会在设置断点的 start_kernel 处停下来，使用list可以查看这段代码。

用b sys_time设置一个断点，启动MenuOS后执行time命令，程序会停到 sys_time 这个函数的位置，time命令执行到一半卡在那里。

gdb调试可以看到Breakpoint在 linux-3.18.6/kernel/time/time.c 中的这个文件，因为是使用宏定义，所以无法直接看到 sys_time。
使用list命令列出的sys_time对应的代码如下：

单步执行，会进入get_seconds() 中所在的 linux-3.18.6/kernel/time/timekeeping.c 文件。

使用finish命令把这个函数全部执行完。

再单步执行，一直到 return i，获得的就是当前系统时间time的数值。

再设置一个断点system_call，继续执行，会发现time函数返回了。

但是在 MenuOS 中执行 time-asm 命令时候，还是停在了原先设定的 sys_time 这个位置，在 system_call 这个位置它并不能停下来。

因为 system_call 不是一个普通的函数，它是一段特殊的汇编代码，只能调试系统调用的内核函数和其他内核函数的处理过程，但gdb不能跟踪 entry_32.s 这个汇编代码。

遇到的问题：

问题原因：没有克隆新版本的menu。

解决办法：用git clone克隆一个新版本的menu，就会增加新的命令time和time-asm。

3.系统调用在内核代码中的处理过程

system_call流程示意图：

从系统调用处理过程的入口开始，就也可以看到SAVE_ALL保存现场，然后找到syscall_call和sys_call_table。之后restore_all和最后的TNTERRUPT_RETURN(iret)用于恢复现场并且返回系统调用到用户态结束。这个过程可能会执行 syscall_exit_work，需要跳转到 work_pending ，里面有work_notifysig 处理信号，还有 work_resched 是需要重新调度的，这里是进程调度的时机点 call schedule ，调度完之后就会跳转到 restore_all ，恢复现场返回系统调用到用户态。