MIT6.828_LAB4_PartB_Copy-on-Write Fork

Part B: Copy-on-Write Fork

正如先前所提到的,Unix提供了fork()系统调用作为创建进程原语,fork()会将父进程的地址空间复制来创建一个子进程。
xv6 Unix通过将父进程所有页的数据复制到新分配给子进程的页上实现了fork(),实际上dumbfork()中也采用了相同的方法,复制父进程的地址空间到子进程是fork()操作中开销最大的部分。
但是，在子进程中fork()之后通常紧接着是对exec（）的调用，新程序会替换掉子进程的内存。 这就是shell程序通常所做的事情。 在这种情况下，复制父进程地址空间所花费的时间被大大浪费了，因为子进程在调用exec（）之前只会使用很少的内存。
因此，Unix之后的版本利用虚拟内存硬件来允许父进程和子进程共享映射到其各自地址空间的内存，直到其中一个进程实际对其进行修改为止。这种技术称为copy-on-write。为此，内核将在fork（）上将地址空间映射从父进程复制到子进程，而不是将实际页面的内容复制过去，同时将当前共享的页面标记为只读。当两个进程之一尝试写入这些共享页面之一时，该进程将导致页面错误。此时，Unix内核意识到该页面实际上是“virtual”副本或“copy-on-write”副本，因此它为导致错误的进程创建了新的，私有的，可写的副本。这样，各个页面的内容实际上不会被复制，直到它们被实际写入为止。这种优化使fork（）之后调用exec()的子进程不必要的开销变小了许多：子进程在调用exec（）之前可能只需要复制一页（其堆栈的当前页）。
在本实验的下一部分中,我们将实现一个具有copy-on-write功能的类unix fork(),作为一个用户空间库例程,在用户空间实现fork()和copy-on-write有助于保持内核的精简性和正确性,它还允许单个用户程序为fork（）定义自己的语义。 想要一个稍有不同的fork()的程序（例如，类似dumbfork（）的完全复制版本，或者父子进程间共享内存的版本）可以轻松地进行修改。

User-level page fault handling

用户级别的copy-on-write fork（）需要知道受写保护的页面上的页面错误，因此这是首先要实现的。 copy-on-write只是用户级页面错误处理的多种可能用途之一。
设置地址空间是很常见的，以便页面错误指示何时需要执行某些操作。 例如，大多数Unix内核最初只在新进程的堆栈区域中映射单个页面，然后在该进程的堆栈消耗增加时“按需”分配和映射其他堆栈页面，并在尚未映射的堆栈地址上引起页面错误。 典型的Unix内核必须跟踪在进程空间的每个区域中发生页面错误时应采取的措施。 例如，堆栈区域中的故障通常将分配并映射新的物理内存页面。 程序的BSS区域中的故障通常会分配一个新页面，并用零填充并映射它。 在具有按需分页的可执行文件的系统中，文本区域中的错误将从磁盘读取二进制文件的相应页面，然后将其映射。
这是内核要跟踪的很多信息。 我们无需采取传统的Unix方法，而可以决定如何处理用户空间中每个页面错误(这些错误对破坏性的影响较小)。 这种设计的附加好处是允许程序在定义其内存区域时具有极大的灵活性。 我们稍后将使用用户级页面错误处理来映射和访问基于磁盘的文件系统上的文件。
为了处理自己的页面错误，用户进程需要在JOS内核中注册页面错误处理程序入口点。 用户进程通过新的sys_env_set_pgfault_upcall系统调用注册其页面错误入口点。 我们在Env结构中添加了一个新成员env_pgfault_upcall，以记录此信息。
练习8.实现sys_env_set_pgfault_upcall系统调用。 查找目标进程的进程ID时，请确保启用权限检查，因为这是“危险的”系统调用。
sys_env_set_pgfault_upcall:

别忘了在syscall函数中加上这一行: