MIT 6.S081 (BOOK-RISCV-REV1)教材第四章内容 --Trap -- 上

MIT 6.S081 教材第四章内容 -- Trap -- 上

引言

MIT 6.S081 2020 操作系统

本文为MIT 6.S081课程第四章教材内容翻译加整理。

本课程前置知识主要涉及:

• C语言(建议阅读C程序语言设计—第二版)
• RISC-V汇编
• 推荐阅读: 程序员的自我修养-装载，链接与库

陷阱指令和系统调用

有三种事件会导致CPU搁置普通指令的执行，并强制将控制权转移到处理该事件的特殊代码上:

• 一种情况是系统调用，当用户程序执行ecall指令要求内核为其做些什么时；
• 另一种情况是异常：（用户或内核）指令做了一些非法的事情，例如除以零或使用无效的虚拟地址；
• 第三种情况是设备中断，一个设备，例如当磁盘硬件完成读或写请求时，向系统表明它需要被关注。

本书使用陷阱（trap）作为这些情况的通用术语。

通常，陷阱发生时正在执行的任何代码都需要稍后恢复，并且不需要意识到发生了任何特殊的事情。

• 也就是说，我们经常希望陷阱是透明的；这对于中断尤其重要，中断代码通常难以预料。
• 通常的顺序是陷阱强制将控制权转移到内核；
• 内核保存寄存器和其他状态，以便可以恢复执行；
• 内核执行适当的处理程序代码（例如，系统调用接口或设备驱动程序）；
• 内核恢复保存的状态并从陷阱中返回；
• 原始代码从它停止的地方恢复。

xv6内核处理所有陷阱。这对于系统调用来说是顺理成章的。由于隔离性要求用户进程不直接使用设备，而且只有内核具有设备处理所需的状态，因而对中断也是有意义的。因为xv6通过杀死违规程序来响应用户空间中的所有异常，它也对异常有意义。

Xv6陷阱处理分为四个阶段：

• RISC-V CPU采取的硬件操作
• 为内核C代码执行而准备的汇编程序集“向量”
• 决定如何处理陷阱的C陷阱处理程序
• 以及系统调用或设备驱动程序服务例程。

虽然三种陷阱类型之间的共性表明内核可以用一个代码路径处理所有陷阱，但对于三种不同的情况：来自用户空间的陷阱、来自内核空间的陷阱和定时器中断，分别使用单独的程序集向量和C陷阱处理程序更加方便。

RISC-V陷入机制

每个RISC-V CPU都有一组控制寄存器，内核通过向这些寄存器写入内容来告诉CPU如何处理陷阱，内核可以读取这些寄存器来明确已经发生的陷阱。RISC-V文档包含了完整的内容。riscv.h(kernel/riscv.h:1)包含在xv6中使用到的内容的定义。以下是最重要的一些寄存器概述：

• stvec：内核在这里写入其陷阱处理程序的地址；RISC-V跳转到这里处理陷阱。
• sepc：当发生陷阱时，RISC-V会在这里保存程序计数器pc（因为pc会被stvec覆盖）。sret（从陷阱返回）指令会将sepc复制到pc。内核可以写入sepc来控制sret的去向。
• scause： RISC-V在这里放置一个描述陷阱原因的数字。
• sscratch：内核在这里放置了一个值，这个值在陷阱处理程序一开始就会派上用场。
• sstatus：其中的SIE位控制设备中断是否启用。如果内核清空SIE，RISC-V将推迟设备中断，直到内核重新设置SIE。SPP位指示陷阱是来自用户模式还是管理模式，并控制sret返回的模式。

上述寄存器都用于在管理模式下处理陷阱，在用户模式下不能读取或写入。在机器模式下处理陷阱有一组等效的控制寄存器，xv6仅在计时器中断的特殊情况下使用它们。

多核芯片上的每个CPU都有自己的这些寄存器集，并且在任何给定时间都可能有多个CPU在处理陷阱。

当需要强制执行陷阱时，RISC-V硬件对所有陷阱类型（计时器中断除外）执行以下操作：

1. 如果陷阱是设备中断，并且状态SIE位被清空，则不执行以下任何操作。
2. 清除SIE以禁用中断。
3. 将pc复制到sepc。
4. 将当前模式（用户或管理）保存在状态的SPP位中。
5. 设置scause以反映产生陷阱的原因。
6. 将模式设置为管理模式。
7. 将stvec复制到pc。
8. 在新的pc上开始执行。

请注意，CPU不会切换到内核页表，不会切换到内核栈，也不会保存除pc之外的任何寄存器。内核软件必须执行这些任务。CPU在陷阱期间执行尽可能少量工作的一个原因是为软件提供灵活性；

• 例如，一些操作系统在某些情况下不需要页表切换，这可以提高性能。

你可能想知道CPU硬件的陷阱处理顺序是否可以进一步简化：

• 例如，假设CPU不切换程序计数器。那么陷阱可以在仍然运行用户指令的情况下切换到管理模式。
• 但因此这些用户指令可以打破用户/内核的隔离机制，例如通过修改satp寄存器来指向允许访问所有物理内存的页表。
• 因此，CPU使用专门的寄存器切换到内核指定的指令地址，即stvec，是很重要的。

代码：调用系统调用

第2章以initcode.S调用exec系统调用（user/initcode.S:11）结束。让我们看看用户调用是如何在内核中实现exec系统调用的。

首选，我们来回滚一下initcode被调用的流程:

1. main函数中完成系统初始化工作

在这里插入图片描述

1. userinit实现对init进程的初始化工作

在这里插入图片描述

前面章节讲过的代码，后续章节都不会再进行讲解，只会讲解未讲过的。

1. scheduler完成0号进程的调度执行

hart0会在系统各个模块初始化任务完成后，唤醒其他hart ， 然后scheduler调度0号init程序执行，而后续其他hart也会调度scheduler，然后不断轮询，等待可被调度的任务出现。

如何获取当前CPU的信息:

1. swtch切换到0号进程执行

在这里插入图片描述

swtch函数最终会跳回ra寄存器指向的地址继续执行，那么0号init进程的proc->context上下文中的ra寄存器的值是在何时设置的呢？毕竟如果不进行设置，这里无法正确跳转到initcode代码段执行。

• 每个新创建出来的进程，其ra寄存器是在allocproc函数中进行的设置，上面我们直接跳过了该函数，下面我们深入分析一下

这里有一个概念大家需要注意区分一下:

在这里插入图片描述

allocproc函数在初始化进程结构体时，会设置context中的ra寄存器指向forkret函数，该函数负责完成内核态返回到用户态的工作。

scheduler函数中调用swtch完成内核态上下文的保存和恢复，将当前hart上正在运行的进程的内核态上下文保存到context中，然后将即将被调度执行的进程的内核态上下文进行恢复:

此时ra寄存器会被恢复为指向forkret函数的地址，然后swtch函数最后执行ret函数，跳转到forkret函数入口地址处执行，完成内核态到用户态的切换，这个切换的具体过程是下一部分我们要重点分析的过程。

forkret函数负责完成内核态到用户态的切换，通过trapframe恢复用户态上下文，此时sepc被赋值为userinit 0号进程初始化函数中被设置的trapframe->epc的值，然后执行sret完成S态到U态的切换，pc寄存器被赋值为spec，我们跳转到了initcode代码段入口地址处执行:

在这里插入图片描述

用户代码将exec需要的参数放在寄存器a0和a1中，并将系统调用号放在a7中。

系统调用号与syscalls数组中的条目相匹配，syscalls数组是一个函数指针表（kernel/syscall.c:108）。

在这里插入图片描述

ecall指令陷入(trap)到内核中，执行uservec、usertrap和syscall，这个过程我们将会在下面详细分析。

syscall（kernel/syscall.c:133）从陷阱帧（trapframe）中保存的a7中检索系统调用号（p->trapframe->a7），并用它索引到syscalls中，对于第一次系统调用，a7中的内容是SYS_exec（kernel/syscall. h:8），导致了对系统调用接口函数sys_exec的调用。

当系统调用接口函数返回时，syscall将其返回值记录在p->trapframe->a0中。这将导致原始用户空间对exec()的调用返回该值，因为RISC-V上的C调用约定将返回值放在a0中。系统调用通常返回负数表示错误，返回零或正数表示成功。如果系统调用号无效，syscall打印错误并返回-1。

从用户空间陷入

我们紧接上一part的流程继续往下分析，当我们在swtch函数中通过ret指令跳转到forkret函数时，forkret内核会干什么呢？

注意:

• 在xv6中，文件系统初始化必须在一个正常的进程上下文中进行，因为它需要执行一些可能会导致进程阻塞或休眠的操作。这些操作包括从磁盘上读取文件系统数据以及建立与硬件设备的连接。
• 如果文件系统初始化在main()之前进行，那么它将在内核启动时进行，此时还没有正常的进程上下文可用。如果在这种情况下尝试执行与进程相关的操作，例如调用sleep()函数等待I/O完成，那么就会导致死锁，因为当前没有任何进程可以运行。
• 为了避免这个问题，在xv6中，文件系统初始化被推迟到第一个进程被创建并开始执行之后。这样，文件系统初始化就在正常的进程上下文中进行，并且可以安全地进行可能会导致进程阻塞或休眠的操作。

usertrapret函数中会执行S态返回用户态的操作:

trampoline，uservec，userret是定义在trampoline.S中的三个全局符号,其中trampoline 符号是一个占位符标记，并不包含任何指令地址，它的存在只是为了让代码可以被正确地映射到用户空间和内核空间相同的虚拟地址:

在这里插入图片描述

• uservec用于用户态进入内核态时，进行用户态寄存器上下文环境的保存。
• userret用于内核态返回用户态时，进行用户态寄存器上下文环境的恢复

同时，通过.section trampsec 语句用于创建一个名为 trampsec 的新节,而trampoline.S汇编文件后面做的事情，则是定义该节中包含哪些符号，在kernel.ld链接器脚本中会搜集名为trampsec的节，并将其放置在代码段后面:

在这里插入图片描述

kvminit内核页表初始化函数中，最后会将trampoline映射到内核虚拟地址空间最高处，大小为一个物理页。

同时，通过链接器脚本可知，.text节中包含了内核原本的所有代码节和trampsec节，所以可知，最终得到的代码段不仅包含了原有的内核代码，还包含了trampsec节相关指令。

又因为kvminit函数中已经对代码段进行了等价映射，又在最后单独将trampsec节的内容映射到内核虚拟地址空间最高处，实际上是将一块物理内存映射到了内核虚拟地址空间两处地方，但是我们只会通过访问内核虚拟地址最高地址处，来访问trampsec节的内容:

在这里插入图片描述

kvmmap第二个参数中只需要传入trampoline全局符号的物理地址即可，因为trampoline全局符号的地址就是trampsec节在物理内存上的起始地址，映射大小为一页，刚好包含了整个trampsec节的内容。

所以usertrapret函数中涉及到的trampoline，uservec，userret三个符号的运算实际目的如下图所示:

在这里插入图片描述

在这里插入图片描述

返回用户空间的是通过调用usertrapret (kernel/trap.c:90)完成的。

• 该函数设置RISC-V控制寄存器，为将来来自用户空间的陷阱做准备。
• 这涉及到将stvec更改为指向uservec，准备uservec所依赖的陷阱帧字段，并将sepc设置为之前保存的用户程序计数器。
• 最后，usertrapret在用户和内核页表中都映射的蹦床页面上调用userret；
• 原因是userret中的汇编代码会切换页表。

usertrapret函数在关闭S态全局中断，更改stvec指向uservec，设置好trapframe相关待恢复上下文，sstatus寄存器相关Previous值，sepc寄存器和satp寄存器待恢复的值后，调用userret函数，并传入trapframe地址和satp寄存器的应该恢复值。

下面我们来看看userret这段汇编过程调用都干了啥:

在这里插入图片描述

usertrapret对userret的调用将指针传递到a0中的进程用户页表和a1中的TRAPFRAME (kernel/trampoline.S:88)。

• userret将satp切换到进程的用户页表。
• 回想一下，用户页表同时映射蹦床页面和TRAPFRAME，但没有从内核映射其他内容。
• 同样，蹦床页面映射在用户和内核页表中的同一个虚拟地址上的事实允许用户在更改satp后继续执行。
• userret复制陷阱帧保存的用户a0到sscratch，为以后与TRAPFRAME的交换做准备。
• 从此刻开始，userret可以使用的唯一数据是寄存器内容和陷阱帧的内容。
• 下一个userret从陷阱帧中恢复保存的用户寄存器，做a0与sscratch的最后一次交换来恢复用户a0并为下一个陷阱保存TRAPFRAME，并使用sret返回用户空间。

userret函数进行trap返回，跳转到设置好的sepc地址处执行，这里就是initcode代码的入口地址处，并且页表完成了切换，所以使用的是当前进程用户态页表进行虚地址翻译。

initcode代码执行的实际是ecall系统调用，调用的syscall_exec函数:

在这里插入图片描述

ecall指令干了什么呢 ?

如果用户程序发出系统调用（ecall指令），或者做了一些非法的事情，或者设备中断，那么在用户空间中执行时就可能会产生陷阱。

• 来自用户空间的陷阱的高级路径是uservec (kernel/trampoline.S:16)
• 然后是usertrap (kernel/trap.c:37)；
• 返回时，先是usertrapret (kernel/trap.c:90)
• 然后是userret (kernel/trampoline.S:16)

ecall指令本质是产生异常，从而打断当前程序正常执行，进入异常指令流，也就是stvec寄存器指向的异常处理程序入口地址，stvec寄存器初始是在trapinithart中被设置:

在这里插入图片描述

kernelvec用于处理发生在S态下的所有中断和异常，但是如果是处于用户态下的程序发生了中断或者异常，则会跳转到uservec地址处执行，因为我们在usertrapret函数中将stvec更改为指向uservec，这样从S态返回到U态后，如果发生了异常或者中断，就都会跳转到uservec地址处执行了。

在这里插入图片描述

uservec负责完成用户态切换到内核态时，用户态下寄存器上下文环境的保存:

trap发生时，硬件会自动保存当前特权级到SPP，SIE到SPIE，pc到spec , 同时关闭全局中断。

来自用户代码的陷阱比来自内核的陷阱更具挑战性，因为satp指向不映射内核的用户页表，栈指针可能包含无效甚至恶意的值。

由于RISC-V硬件在陷阱期间不会切换页表，所以用户页表必须包括uservec（stvec指向的陷阱向量指令）的映射。uservec必须切换satp以指向内核页表；为了在切换后继续执行指令，uservec必须在内核页表中与用户页表中映射相同的地址。

xv6使用包含uservec的蹦床页面（trampoline page）来满足这些约束。xv6将蹦床页面映射到内核页表和每个用户页表中相同的虚拟地址。这个虚拟地址是TRAMPOLINE。蹦床内容在trampoline.S中设置，并且（当执行用户代码时）stvec设置为uservec (kernel/trampoline.S:16)。

在这里插入图片描述

当uservec启动时，所有32个寄存器都包含被中断代码所拥有的值。但是uservec需要能够修改一些寄存器，以便设置satp并生成保存寄存器的地址。RISC-V以sscratch寄存器的形式提供了帮助。uservec开始时的csrrw指令交换了a0和sscratch的内容。现在用户代码的a0被保存了；uservec有一个寄存器（a0）可以使用；a0包含内核以前放在sscratch中的值。

uservec的下一个任务是保存用户寄存器。在进入用户空间之前，内核先前将sscratch设置为指向一个每个进程的陷阱帧，该帧（除此之外）具有保存所有用户寄存器的空间(kernel/proc.h:44)。因为satp仍然指向用户页表，所以uservec需要将陷阱帧映射到用户地址空间中。每当创建一个进程时，xv6就为该进程的陷阱帧分配一个页面，并安排它始终映射在用户虚拟地址TRAPFRAME，该地址就在TRAMPOLINE下面。尽管使用物理地址，该进程的p->trapframe仍指向陷阱帧，这样内核就可以通过内核页表使用它。

因此在交换a0和sscratch之后，a0持有指向当前进程陷阱帧的指针。uservec现在保存那里的所有用户寄存器，包括从sscratch读取的用户的a0。

陷阱帧包含指向当前进程内核栈的指针、当前CPU的hartid、usertrap的地址和内核页表的地址。uservec取得这些值，将satp切换到内核页表，并调用usertrap。

uservec函数再完成用户态寄存器环境上下文保存后，跳转到usertrap继续执行:

usertrap的任务是确定陷阱的原因，处理并返回(kernel/trap.c:37)。

• 如上所述，它首先改变stvec，这样内核中的陷阱将由kernelvec处理。
• 它保存了sepc（保存的用户程序计数器），再次保存是因为usertrap中可能有一个进程切换，可能导致sepc被覆盖。
• 如果陷阱来自系统调用，syscall会处理它；
• 如果是设备中断，devintr会处理；
• 否则它是一个异常，内核会杀死错误进程。
• 系统调用路径在保存的用户程序计数器pc上加4，因为在系统调用的情况下，RISC-V会留下指向ecall指令的程序指针（返回后需要执行ecall之后的下一条指令）。
• 在退出的过程中，usertrap检查进程是已经被杀死还是应该让出CPU（如果这个陷阱是计时器中断）。
• 最后调用usertrapret进行trap返回，这个函数已经分析过了,这里不再多讲

系统调用参数

内核中的系统调用接口需要找到用户代码传递的参数。因为用户代码调用了系统调用封装函数，所以参数最初被放置在RISC-V C调用所约定的地方：寄存器。

内核陷阱代码将用户寄存器保存到当前进程的陷阱框架中，内核代码可以在那里找到它们。函数artint、artaddr和artfd从陷阱框架中检索第n个系统调用参数并以整数、指针或文件描述符的形式保存。他们都调用argraw来检索相应的保存的用户寄存器（kernel/syscall.c:35）。

在这里插入图片描述

有些系统调用传递指针作为参数，内核必须使用这些指针来读取或写入用户内存。

• 例如：exec系统调用传递给内核一个指向用户空间中字符串参数的指针数组。
• 这些指针带来了两个挑战。
  • 首先，用户程序可能有缺陷或恶意，可能会传递给内核一个无效的指针，或者一个旨在欺骗内核访问内核内存而不是用户内存的指针。
  • 其次，xv6内核页表映射与用户页表映射不同，因此内核不能使用普通指令从用户提供的地址加载或存储。

内核实现了安全地将数据传输到用户提供的地址和从用户提供的地址传输数据的功能。

• fetchstr是一个例子（kernel/syscall.c:25）。
• 文件系统调用，如exec，使用fetchstr从用户空间检索字符串文件名参数。
• fetchstr调用copyinstr来完成这项困难的工作。

copyinstr（kernel/vm.c:406）从用户页表中的虚拟地址srcva复制max字节到dst。

• 它使用walkaddr（它又调用walk）在软件中遍历页表，以确定srcva的物理地址pa0。
• 由于内核将所有物理RAM地址映射到同一个内核虚拟地址，
• copyinstr可以直接将字符串字节从pa0复制到dst。
• walkaddr（kernel/vm.c:95）检查用户提供的虚拟地址是否为进程用户地址空间的一部分，因此程序不能欺骗内核读取其他内存。
• 一个类似的函数copyout，将数据从内核复制到用户提供的地址。

如果做过页表节实验小伙伴可能知道，由于我们为每个进程在内核中增加了自己的内核页表，并将用户态下的内存通样映射到了每个进程自己的内核页表中，所以传入的用户态指针可以直接在内核态下进行解引用，下面是上一节实验改造后的copystr实现:

补充

下面补充视频课程中提到的一些点,虽然上面都提到了，但是可能有些地方教材描述的不是特别清楚，我附加的说明也不够到位，所以还是给出视频中大佬通俗易懂的讲解:

1. trap处理过程中，我们需要关注哪些寄存器?

• 32个用户寄存器，RISC-V总共有32个比如a0，a1这样的寄存器，用户应用程序可以使用全部的寄存器，并且使用寄存器的指令性能是最好的。
• 寄存器是stack pointer（也叫做堆栈寄存器 stack register）
• 程序计数器（Program Counter Register）
• 表明当前mode的标志位，这个标志位表明了当前是supervisor mode还是user mode。当我们在运行Shell的时候，自然是在user mode。该标志位由硬件负责维护,代码不可见，我们只能通过XPP来间接控制当前特权级切换。
• 还有一堆控制CPU工作方式的寄存器(CSR)
  • 比如SATP（Supervisor Address Translation and Protection）寄存器，它包含了指向page table的物理内存地址
  • 比如STVEC（Supervisor Trap Vector Base Address Register）寄存器，它指向了内核中处理trap的指令的起始地址
• SEPC（Supervisor Exception Program Counter）寄存器，在trap的过程中保存程序计数器的值
• SSRATCH（Supervisor Scratch Register）寄存器，这也是个非常重要的寄存器
• 这些寄存器表明了执行系统调用时计算机的状态。

1. trap发生时，我们需要做些什么?

• 首先，我们需要保存32个用户寄存器。因为很显然我们需要恢复用户应用程序的执行，尤其是当用户程序随机的被设备中断所打断时。我们希望内核能够响应中断，之后在用户程序完全无感知的情况下再恢复用户代码的执行。所以这意味着32个用户寄存器不能被内核弄乱。但是这些寄存器又要被内核代码所使用，所以在trap之前，你必须先在某处保存这32个用户寄存器。
• 程序计数器也需要在某个地方保存，它几乎跟一个用户寄存器的地位是一样的，我们需要能够在用户程序运行中断的位置继续执行用户程序。
• 我们需要将mode改成supervisor mode，因为我们想要使用内核中的各种各样的特权指令。
• SATP寄存器现在正指向user page table，而user page table只包含了用户程序所需要的内存映射和一两个其他的映射，它并没有包含整个内核数据的内存映射。所以在运行内核代码之前，我们需要将SATP指向kernel page table。
• 我们需要将堆栈寄存器指向位于内核的一个地址，因为我们需要一个堆栈来调用内核的C函数。
• 一旦我们设置好了，并且所有的硬件状态都适合在内核中使用， 我们需要跳入内核的C代码。
• 一旦我们运行在内核的C代码中，那就跟平常的C代码是一样的。

• 操作系统的一些high-level的目标能帮我们过滤一些实现选项。其中一个目标是安全和隔离，我们不想让用户代码介入到这里的user/kernel切换，否则有可能会破坏安全性。所以这意味着，trap中涉及到的硬件和内核机制不能依赖任何来自用户空间东西。比如说我们不能依赖32个用户寄存器，它们可能保存的是恶意的数据，所以，XV6的trap机制不会查看这些寄存器，而只是将它们保存起来。
• 在操作系统的trap机制中，我们仍然想保留隔离性并防御来自用户代码的可能的恶意攻击。同样也很重要的是，另一方面，我们想要让trap机制对用户代码是透明的，也就是说我们想要执行trap，然后在内核中执行代码，同时用户代码并不用察觉到任何有意思的事情。这样也更容易写用户代码。

1. 在supervisor mode完成，但是不能在user mode完成的工作，或许并没有你想象的那么有特权。所以，我们接下来看看supervisor mode可以控制什么？

• 其中的一件事情是，你现在可以读写控制寄存器(CSR)了。
  • 比如说，当你在supervisor mode时，你可以：读写SATP寄存器，也就是page table的指针；
  • STVEC，也就是处理trap的内核指令地址；
  • SEPC，保存当发生trap时的程序计数器；
  • SSCRATCH等等。
  • 在supervisor mode你可以读写这些寄存器，而用户代码不能做这样的操作。
• 另一件事情supervisor mode可以做的是，它可以使用PTE_U标志位为0的PTE。
  • 当PTE_U标志位为1的时候，表明用户代码可以使用这个页表；
  • 如果这个标志位为0，则只有supervisor mode可以使用这个页表。
• 这两点就是supervisor mode可以做的事情，除此之外就不能再干别的事情了。
• 需要特别指出的是，supervisor mode中的代码并不能读写任意物理地址。在supervisor mode中，就像普通的用户代码一样，也需要通过page table来访问内存。
• 如果一个虚拟地址并不在当前由SATP指向的page table中，又或者SATP指向的page table中PTE_U=1，那么supervisor mode不能使用那个地址。
• 所以，即使我们在supervisor mode，我们还是受限于当前page table设置的虚拟地址。

1. vm.c里的函数为什么可以直接访问物理内存？

• 这些函数能这么做的原因是，内核小心的在page table中设置好了各个PTE。
• 这样当内核收到了一个读写虚拟内存地址的请求，会通过kernel page table将这个虚拟内存地址翻译成与之等价物理内存地址，再完成读写。
• 所以，一旦使用了kernel page table，就可以非常方便的在内核中使用所有这些直接的映射关系。
• 但是直到trap机制切换到内核之前，这些映射关系都不可用。
• 直到trap机制将程序运行切换到内核空间之前，我们使用的仍然是没有这些方便映射关系的user page table。

1. read和write系统调用，相比内存的读写，他们的代价都高的多，因为它们需要切换模式，并来回捣腾。有没有可能当你执行打开一个文件的系统调用时， 直接得到一个page table映射，而不是返回一个文件描述符？这样只需要向对应于设备的特定的地址写数据，程序就能通过page table访问特定的设备。你可以设置好限制，就像文件描述符只允许修改特定文件一样，这样就不用像系统调用一样在用户空间和内核空间来回捣腾了。

• 这是个很好的想法。实际上很多操作系统都提供这种叫做内存映射文件（Memory-mapped file access）的机制，在这个机制里面通过page table，可以将用户空间的虚拟地址空间，对应到文件内容，这样你就可以通过内存地址直接读写文件。
• 实际上，你们将在mmap 实验中完成这个机制。
• 对于许多程序来说，这个机制的确会比直接调用read/write系统调用要快的多。

本节内容已经足够多了，后续的内容将会在下一小节进行补充说明。