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

一 、万能函数

1、过程抽象

（1）接口：指明模块要做什么，标识符/类型、函数等，.h ，函数调用者

（2）实现：指明模块如何完成接口，一个接口多个实现（可能），.c ，函数实现者

（3）函数签名：函数名、它的参数个数，参数类型，注意不包含返回值。函数签名用于识别不同的函数，就像签名用于识别不同的人一样。关键是参数的数量和类型。

2、单线程

并发：程序级并发——进程 函数系并发——线程

二、实验

1、查看menu

该系统下载到我的ubuntu原镜像的hadoop用户下的LinuxKernel中，下载好menu后，进入menu，查看test.c

编译时出现问题:

经过查阅资料，得知，可能是内存不够的原因：



修改内存：

进行make rootfs，成功：

执行两个命令：

2、使用gdb跟踪系统调用黑盒函数sys_time

启动内核：



命令中-S -s用于gdb调试

进入gdb调试：target remote：1234进行连接到需要调试的MenuOS

为什么是1234呢？因为-s是在1234端口上创建了一个gdb-server

进入gdb之后，设置断点，为什么没有设置到文件中某一具体行，如图中红框所示：

继续向下做：



卡在断点处

继续往后，使用list，报错，目前没有找到解决办法

执行给system_call设置断点，使用c键继续执行，可以看到time指令已经执行。

执行time_asm时，没有反应：

三、系统调用在内核代码的处理过程

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

\init\main.c start_kernel中有个trap_init()

\arc\x86\kernel\traps.c

ifdef CONFIG_X86_32

     set_system_trap_gate(SYSCALL_VECTOR,&system_call); //系统调用的中断向量，system_call代表汇编代码入口，set_system_trap_gate用来绑定中断向量0x86和system_call中断服务程序入口。
     set_bit(SYSCALL_VECTOR，used_vectors)

endif

system_call这一段代码就是系统调用的处理过程，系统调用是一个特殊一点的中断（或称之为软中断），这一段代码中也有保存现场SAVE_ALL和恢复现场restore_all的过程。同时，system_call_table是一个系统调用的表，EAX寄存器传递的系统调用号，使用者在调用它时会根据EAX寄存器来调用对应的系统调用内核处理函数。

ENTRY(system_call)

RING0_INT_FRAME

ASM_CLAC

pushl_cfi %eax #保存系统调用号

SAVE_ALL #保存现场，将用到的所有CPU寄存器保存到栈中

GET_THREAD_INFO(%ebp) #ebp用于存放当前进程thread_info结构的地址

testl $_TIF_WORK_SYSCALL_ENTRY, TI_flags(%ebp)

jnz syscall_trace_entry

cmpl $(nr_syscalls), %eax #检查系统调用号（系统调用号应小于NR_syscalls）

jae syscall_badsys #不合法，跳入异常处理

syscall_call:

call *sys_call_table(,%eax,4) #通过系统调用号在系统调用表中找到相应的系统调用内核处理函数，比如sys_time

movl %eax, PT_EAX(%esp) #保存返回值到栈中

syscall_exit:

testl $_TIF_ALLWORK_MASK, %ecx #检查是否有任务需要处理

jne syscall_exit_work #需要，进入syscall_exit_work，这里是最常见的进程调度时机

restore_all:

TRACE_IRQS_TRET #恢复现场

irq_return:

INTERRUPT_RETURN #iret

int x80（触发系统调用）会立即跳转到entry中，system_call（系统调用的入口）的位置，根据系统调用号查找sys_call_table表（系统调用表），syscall_exit_work最常见的进程调度时机。SYSCALL_VECTOR是系统调用的中断向量0x80。

四、总结

本周做的这个实验有点问题，在网上查找解决办法，但是相关资料比较少，暂时不知道解决办法。在本周的学习中，学习了关于系统调用的内核处理过程。