OS-lab4
系统调用
系统调用的流程
按照上述的流程逐个分析。
-
user/syscall_lib.c
这个文件位于user文件夹下，也就是用户程序可以调用的函数，相当于操作系统提供给用户程序的一些库函数。里面定义了一系列系统调用函数如
syscall_putchar、syscall_yeild等，而这些函数都通过调用msyscall实现。 -
user/syscall_wrap.S
这个汇编文件定义了
msyscall函数，也就是通过一个syscall指令使得操作系统陷入内核。经过lab3中的异常分发，就能够定位到处理syscall这类指令引起的异常的函数。 -
lib/syscall.S
这个汇编文件定义了
handle_sys函数，也就是专门用于处理系统调用异常的函数，准确地说，这个函数是预处理一些信息。首先是保存现场关中断；接着需要判断CP0_CAUSE寄存器中的BD位，也就是判断是否是延时槽指令，根据这个修改CP0_EPC的值(我觉得有点奇怪，按照计组p7，这一过程是交给硬件来完成的)；接着取出系统调用号处理后获得对应系统调用函数的入口地址；最后将前四个参数载入到a0-a3中，后两个参数压栈，并跳转至对应的系统调用，返回后弹栈。
-
lib/syscall_all.c
这个就是内核态具体处理系统调用的文件，所有的系统调用最后都会到这里。
sys_yield函数用于进行进程调度。首先是将内核栈复制到TIMESTACK中，然后调用sched_yeild进行调度。
sys_mem_alloc函数用于在指定虚拟地址处分配一页给对应的进程。首先需要判断标志位信息和地址合法性，写时复制是不被允许的；接着获得进程控制块；使用page_alloc获得一页内存，再使用page_insert加入到页表中，并增加引用。
sys_mem_map函数用于将一处虚拟地址所在的页面映射到另一处地址，也就相当于这一页内存可以被两个进程共享访问。首先需要对这两个地址向下取整；然后判断标志位和地址合法性接着分别获取两个进程的进程控制块；再使用page_lookup查找源页面，并使用page_insert加入到目标进程的页表中。
sys_mem_unmap函数将指定虚拟地址的映射关系移除。先找到进程控制块，然后使用page_remove移除映射关系。
上面就是第一部分主要完成的内容，实现了用户态函数调用到操作系统内核实现的完整过程。
进程间通信
-
user/ipc.c
这个文件中定义了进程间通信基本的函数
ipc_send和ipc_recv。ipc_send函数用于尝试发送信息。主体是一个循环，利用系统调用函数不断判断是否能够发送，若不能发送则调用syscall_yeild进行调度。
ipc_recv函数用于接收信息。首先是调用syscall_ipc_recv接受地址信息，然后设置接收进程的信息，返回接收到的信息。这两个函数的核心分别基于两个系统调用
syscall_ipc_can_send和syscall_ipc_recv。 -
lib/syscall_all.c
这个文件最后两个函数就是进程通信需要实现的两个函数。
sys_ipc_can_send函数用于尝试向目标进程发送信息。首先判断地址的合法性；然后获取目标进程；判断目标进程的接收状态，如果不能接收则报错，可以接收则则设置相关的信息，并利用page_lookup和page_insert把源页面共享给目标进程，最后要关掉目标进程的接收。
sys_ipc_recv函数就是设置进程使得进程能够接收消息。首先判断地址合法性，然后设置接收状态为可接收，并修改进程运行状态为不可运行，最后进入进程调度。
fork
fork函数用于创建一个子进程。
-
lib/syscall_all.c
fork函数首先需要通过sys_env_alloc来创建一个进程。具体做法则是通过env_alloc得到一个空闲的进程，接着将KERNEL_SP的内容复制到env_tf中，将pc值设为epc，这样子进程就会从父进程fork的地方开始执行，然后设置a0寄存器为0，这样就能保证子进程fork的返回值是0，最后设置进程状态为不可执行，此时子进程的页表等信息还没有设置，所以还不能执行，返回子进程进程号。 -
user/fork.c
创建进程后，需要利用
duppage给子进程设置页表，也就是将父进程的页表复制一份给子进程。对于只读页面、共享页面、写时复制页面只需要按照原来的标志位，以用syscall_mem_map共享给子进程即可，可写页面则需要加上写时复制标记PTE_COW保护，这里需要给子进程和父进程都加上。由于这是用户态程序，所以不能直接访问页表，而是需要通过指向页表的指针vpt来完成。 -
lib/suscall_all.c
接下来需要给子进程设置缺页处理函数，这一操作通过系统调用
syscall_set_pgfault_handler完成，对应内核态函数sys_set_pgfault_handler。这个函数先找到进程控制块，然后给env_pgfault_handler赋上缺页处理函数的地址，给异常处理栈env_xstacktop赋值，然后返回。 -
user/entry.S
上面的系统调用在实际运行中，载入的函数是
__asm_pgfault_handler，这个函数定义在user/entry.S中。但这个函数只完成了处理参数和返回恢复现场的操作，具体缺页处理则是跳转到__pgfault_handler函数，由这个函数来完成。 -
user/fork.c
这个真正的处理函数是
pgfault，这个函数用来处理写时复制引起的缺页异常。首先需要判断这一地址所在页是否是写时复制页面；接着将地址向下取整，在用户栈的位置分配一页，将源页面的内容复制过去，然后把新的页面映射到原来的虚拟地址上，把新的页面的映射移除。 -
user/syscall_all.c
进行到这里，子进程执行的条件就都具备了，这时候需要设置子进程的状态，让子进程可以运行。也就是通过系统调用
sys_set_env_status完成。首先判断状态的合法性，然后获取进程控制块，将进程的状态赋值。
上面的流程全部完成后，返回子进程的进程号，fork函数就基本完成了，但还有个细节没有做到。在给子进程设置了缺页处理函数后，子进程能够处理写时复制异常，但父进程似乎没有设置。因此在写时复制机制完成前，也就是duppage之前，需要利用set_pgfault_handler设置缺页处理函数。
现在fork函数就算完成了。在之后父进程或子进程遇到写时复制异常处理时，就是通过触发异常，经过异常分发确定为写时复制异常，然后通过一个函数跳转到这个进程安装的缺页异常处理函数。这个函数page_fault_handler位于lib/traps.c中，这个函数首先将进程的执行现场复制到临时的Trapframe中，再复制到异常处理栈中，最后设置epc的值，使得接下来进程会进入缺页异常处理函数。
从这个异常处理过程中可以看出微内核的设计思想，真正处理异常的函数处于用户态，交给用户进程来完成，而内核只进行异常分发，跳转到对应处理函数的过程。
梳理一下lab4的整个过程，首先是实现了从用户态到内核态的完整的系统调用流程，中间涉及到了MIPS的函数传参的规定和用户态内核态的转换；接着是完成了进程间通信；最后实现了从创建一个新进程、设置页表和异常处理函数、最后使这个新进程能够正常运行正常处理写时复制的完整过程。
最后的fork函数涉及到了很多系统调用，尤其是缺页异常函数，在完成缺页处理的过程中，首先是触发异常陷入内核，经过异常分发后进入缺页异常处理函数page_fault_handler，接着转到用户态的_asm_pgfault_handler函数，在取出异常指令地址后进入处理异常的核心函数pgfault，处理完后逐层返回。