一 、万能函数
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。
四、总结
本周做的这个实验有点问题，在网上查找解决办法，但是相关资料比较少，暂时不知道解决办法。在本周的学习中，学习了关于系统调用的内核处理过程。