FreeBSD 中的 Linux® 模拟

常见的 UNIX® API 将系统调用定义为从用户空间进程向内核发出命令的一种方式。最常见的实现是使用中断或专门指令（考虑 ia32 的 SYSENTER/SYSCALL 指令）。系统调用由一个数字定义。例如，在 FreeBSD 中，系统调用号 85 是 swapon(2) 系统调用，系统调用号 132 是 mkfifo(2)。某些系统调用需要参数，这些参数以各种方式（实现相关）从用户空间传递到内核空间。系统调用是同步的。

另一种可能的通信方式是使用 陷阱。陷阱在某些事件发生后异步发生（除以零、页面错误等）。陷阱对于进程来说可能是透明的（页面错误），或者可能导致反应，例如发送 信号（除以零）。

还有其他 API（System V IPC、共享内存等），但最重要的 API 是信号。信号由进程或内核发送，并由进程接收。某些信号可以被忽略或由用户提供的例程处理，某些信号会导致无法更改或忽略的预定义操作。

内核实例首先在系统中被处理（所谓的 init）。每个正在运行的进程都可以使用 fork(2) 系统调用创建其自身的副本。引入了此系统调用的某些略微修改的版本，但基本语义相同。每个正在运行的进程都可以使用 exec(3) 系统调用转换为其他进程。引入了此系统调用的某些修改，但所有这些都服务于相同的基本目的。进程通过调用 exit(2) 系统调用结束其生命周期。每个进程都由一个唯一的数字标识，称为 PID。每个进程都有一个定义的父进程（由其 PID 标识）。

传统的 UNIX® 没有定义任何用于线程的 API 或实现，而 POSIX® 定义了其线程 API，但实现未定义。传统上，有两种实现线程的方式。将它们作为单独的进程处理（1:1 线程）或将整个线程组封装在一个进程中并在用户空间中管理线程（1:N 线程）。比较每种方法的主要特性

1:1 线程

1:N 线程

FreeBSD 是传统意义上的 UNIX® 系统，它将进程的运行分为两个部分：内核空间和用户空间运行。进程进入内核有两种方式：系统调用和陷阱。返回的方式只有一种。在接下来的章节中，我们将描述进出内核的三个门。整个描述适用于 i386 架构，因为 Linuxulator 仅存在于此架构中，但概念在其他架构上类似。信息来自 [1] 和源代码。

Linux® 遵循传统的 UNIX® 方案，将进程的运行分为两个部分：内核和用户空间。内核可以通过两种方式进入：通过陷阱或通过系统调用。返回只有一种处理方式。以下描述适用于 i386™ 架构上的 Linux® 2.6。此信息来自 [2]。

贡献者：Attilio Rao <attilio@FreeBSD.org>

FreeBSD 同步原语集基于这样的理念：以一种能够为每个特定、适当的情况使用最佳原语的方式提供相当大量的不同原语。

从高级角度来看，您可以在 FreeBSD 内核中考虑三种同步原语

下面是这三个系列的描述。对于每个锁，您确实应该检查链接的手册页（如果可能），以获取更详细的解释。

各种仿真层有时需要一些额外的每个进程数据。它可以管理包含这些数据的单独结构（列表、树等），用于每个进程，但这往往很慢且消耗内存。为了解决这个问题，FreeBSD proc 结构包含 p_emuldata，它是一个指向一些仿真层特定数据的 void 指针。此 proc 条目受 proc 互斥锁保护。

FreeBSD proc 结构包含一个 p_sysent 条目，用于识别此进程正在运行的 ABI。实际上，它是一个指向上面描述的 sysentvec 的指针。因此，通过将此指针与存储给定 ABI 的 sysentvec 结构的地址进行比较，我们可以有效地确定该进程是否属于我们的仿真层。代码通常如下所示

如您所见，我们有效地使用 __predict_true 修饰符将最常见的情况（FreeBSD 进程）折叠为一个简单的返回操作，从而保持高性能。此代码应转换为宏，因为当前它不够灵活，即我们不支持 Linux®64 仿真，也不支持 i386 上的 A.OUT Linux® 进程。

FreeBSD VFS 子系统非常复杂，但 Linux® 仿真层仅通过定义良好的 API 使用其中的一小部分。它可以对 vnodes 或文件句柄进行操作。Vnode 代表虚拟 vnode，即 VFS 中节点的表示。另一种表示形式是文件句柄，它代表从进程的角度打开的文件。文件句柄可以表示套接字或普通文件。文件句柄包含指向其 vnode 的指针。多个文件句柄可以指向同一个 vnode。

Linux® 通过寄存器将参数传递给系统调用（这就是它在 i386 上仅限于 6 个参数的原因），而 FreeBSD 使用栈。Linux® prepsyscall 例程必须将参数从寄存器复制到栈。寄存器的顺序为：%ebx、%ecx、%edx、%esi、%edi、%ebp。需要注意的是，这仅适用于大多数系统调用。有些（最显著的是 clone）使用不同的顺序，但幸运的是，可以通过在 linux_clone 原型中插入一个虚拟参数来轻松修复。

在 Linuxulator 中实现的每个系统调用都必须在 syscalls.master 中具有其带有各种标志的原型。文件格式如下：

第一列表示系统调用编号。第二列用于审计支持。第三列表示系统调用类型。它可以是 STD、OBSOL、NOPROTO 和 UNIMPL。STD 是具有完整原型和实现的标准系统调用。OBSOL 已过时，仅定义原型。NOPROTO 意味着系统调用在其他地方实现，因此不要添加 ABI 前缀等。UNIMPL 意味着系统调用将被 nosys 系统调用替换（一个系统调用只是打印一条关于系统调用未实现的消息并返回 ENOSYS）。

从 syscalls.master 中，一个脚本生成三个文件：linux_syscall.h、linux_proto.h 和 linux_sysent.c。linux_syscall.h 包含系统调用名称及其数值定义，例如：

linux_proto.h 包含每个系统调用参数的结构定义，例如：

最后，linux_sysent.c 包含描述系统入口表的结构，用于实际调度系统调用，例如：

如您所见，linux_fork 在 Linuxulator 本身中实现，因此定义为 STD 类型且没有参数，这由虚拟参数结构体现。另一方面，close 只是对真实 FreeBSD close(2) 的别名，因此它没有关联的 linux 参数结构，并且在系统入口表中它没有以 linux 为前缀，因为它调用了内核中的真实 close(2)。

Linux® 模拟层并不完整，因为某些系统调用没有正确实现，而另一些则根本没有实现。模拟层采用了一种机制，使用 DUMMY 宏来标记未实现的系统调用。这些虚拟定义位于 linux_dummy.c 中，采用 DUMMY(syscall); 的形式，然后转换为各种系统调用辅助文件，并且实现包括打印一条消息，说明此系统调用未实现。未使用 UNIMPL 原型，因为我们希望能够识别调用的系统调用的名称，以了解哪些系统调用更重要。

此例程首先检查信号是否已使用 SA_SIGINFO 安装，如果是，则改为调用 linux_rt_sendsig 例程。此外，它分配（或重用已存在的）信号处理上下文，然后构建信号处理程序的参数列表。它根据信号转换表转换信号编号，分配处理程序，转换 sigset。然后它保存 sigreturn 例程的上下文（各种寄存器、转换后的陷阱编号和信号掩码）。最后，它将信号上下文复制到用户空间，并为实际的信号处理程序运行准备上下文。

此例程类似于 linux_sendsig，只是信号上下文准备不同。它添加了 siginfo、ucontext 和一些 POSIX® 部分。值得考虑是否可以合并这两个函数，从而减少代码重复，并可能加快执行速度。

此系统调用用于从信号处理程序返回。它执行一些安全检查并恢复原始进程上下文。它还在进程信号掩码中取消屏蔽信号。

FreeBSD 中的 Linux® 模拟层支持在运行时设置模拟的版本。这是通过 sysctl(8) 实现的，具体来说是 compat.linux.osrelease。设置此 sysctl(8) 会影响模拟层的运行时行为。当设置为 2.6.x 时，它会设置 linux_use_linux26 的值，而设置为其他值则保持其未设置状态。此变量（加上相同类型的每个监狱变量）决定代码中是否使用 2.6 基础设施（主要是 PID 转换）。版本设置是在系统范围内进行的，这会影响所有 Linux® 进程。在运行任何 Linux® 二进制文件时，不应更改 sysctl(8)，因为它可能会造成损害。

Linux® 线程的语义有点令人困惑，并且使用与 FreeBSD 完全不同的命名法。Linux® 中的进程由一个 struct task 组成，该结构嵌入两个标识符字段 - PID 和 TGID。PID 不是进程 ID，而是线程 ID。TGID 标识线程组，换句话说就是进程。对于单线程进程，PID 等于 TGID。

NPTL 中的线程只是一个普通的进程，恰好具有不等于 PID 的 TGID，并且具有不等于自身（当然还有共享 VM 等）的组领导者。其他所有事情都与普通进程一样发生。与 FreeBSD 中一样，没有将共享状态分离到某个外部结构中。这会造成一些信息重复和可能的数据不一致。Linux® 内核似乎在某些地方使用 task → group 信息，而在其他地方使用 task 信息，它实际上并不一致，并且看起来容易出错。

每个 NPTL 线程都是通过调用带有特定标志集的 clone 系统调用创建的（下一小节中将详细介绍）。NPTL 实现严格的 1:1 线程。

在 FreeBSD 中，我们使用共享 VM 空间等的普通 FreeBSD 进程来模拟 NPTL 线程，并且 PID 体操只是在附加到进程的模拟特定结构中被模仿。附加到进程的结构如下所示

PID 用于标识附加此结构的 FreeBSD 进程。child_se_tid 和 child_clear_tid 用于在进程退出和创建时进行 TID 地址复制。shared 指针指向线程之间共享的结构。pdeath_signal 变量标识父进程死亡信号，threads 指针用于将此结构链接到线程列表。linux_emuldata_shared 结构如下所示

refs 是一个引用计数器，用于确定何时可以释放结构以避免内存泄漏。group_pid 用于标识整个进程（= 线程组）的 PID（= TGID）。threads 指针是进程中线程列表的头部。

可以使用 em_find 从进程中获取 linux_emuldata 结构。函数的原型如下

这里，proc 是我们想要从中获取 emuldata 结构的进程，而 locked 参数确定我们是否要加锁。可接受的值为 EMUL_DOLOCK 和 EMUL_DOUNLOCK。稍后将详细介绍锁定。

由于 FreeBSD 和 Linux® 对进程 ID 和线程 ID 的概念有不同的看法，因此我们必须以某种方式转换这种看法。我们通过 PID 转换来做到这一点。这意味着我们在内核和用户空间之间伪造 PID（=TGID）和 TID（=PID）是什么。经验法则是，在内核（在 Linuxulator 中）PID = PID 且 TGID = shared → group pid，而在用户空间中，我们呈现 PID = shared → group_pid 和 TID = proc → p_pid。linux_emuldata 结构的 PID 成员是 FreeBSD PID。

上述内容主要影响 getpid、getppid、gettid 系统调用。我们在其中分别使用 PID/TGID。在 child_clear_tid 和 child_set_tid 中复制 TID 时，我们复制出 FreeBSD PID。

clone 系统调用是 Linux® 中创建线程的方式。系统调用的原型如下所示

flags 参数告诉系统调用如何精确地克隆进程。如上所述，Linux® 可以创建共享各种事物的进程，例如两个进程可以共享文件描述符，但不能共享 VM 等。flags 参数的最后一个字节是新创建进程的退出信号。如果 stack 参数不为 NULL，则说明线程堆栈在哪里，如果为 NULL，则表示我们应该复制调用进程堆栈（即执行正常的 fork(2) 例程）。parent_tidptr 参数用作复制进程 PID（即线程 ID）的地址，一旦进程充分实例化但尚未可运行。dummy 参数在这里是因为此系统调用在 i386 上非常奇怪的调用约定。它直接使用寄存器，不允许编译器执行此操作，导致需要一个虚拟系统调用。child_tidptr 参数用作在进程完成分叉以及进程退出时复制 PID 的地址。

系统调用本身通过根据传递的标志设置相应的标志来进行。例如，CLONE_VM 映射到 RFMEM（共享 VM）等。这里唯一的细节是 CLONE_FS 和 CLONE_FILES，因为 FreeBSD 不允许单独设置这些标志，因此如果定义了其中任何一个，我们通过不设置 RFFDG（复制 fd 表和其他 fs 信息）来伪造它。这不会导致任何问题，因为这些标志总是同时设置。设置标志后，使用内部 fork1 例程分叉进程，该进程被设置为不放入运行队列中，即不设置为可运行状态。分叉完成后，我们可能会将新创建的进程重新设置为父进程，以模拟 CLONE_PARENT 语义。下一部分是创建模拟数据。Linux® 中的线程不会向其父进程发送信号，因此我们将退出信号设置为 0 以禁用此功能。之后执行 child_set_tid 和 child_clear_tid 的设置，以便在代码中的后面启用该功能。此时，我们将 PID 复制到 parent_tidptr 指定的地址。进程堆栈的设置是通过简单地重写线程帧 %esp 寄存器（amd64 上的 %rsp）来完成的。下一部分是为新创建的进程设置 TLS。在此之后，可能会模拟 vfork(2) 语义，最后将新创建的进程放入运行队列中，并通过 clone 返回值将 PID 复制到父进程。

clone 系统调用能够并且实际上用于模拟经典的 fork(2) 和 vfork(2) 系统调用。在 2.6 内核的情况下，较新的 glibc 使用 clone 来实现 fork(2) 和 vfork(2) 系统调用。

锁定实现为每个子系统，因为我们预计这些子系统上的争用不多。有两个锁：emul_lock 用于保护 linux_emuldata 的操作，emul_shared_lock 用于操作 linux_emuldata_shared。emul_lock 是一个不可睡眠的阻塞互斥锁，而 emul_shared_lock 是一个可睡眠的阻塞 sx_lock。由于每个子系统的锁定，我们可以合并一些锁，这就是 em find 提供非锁定访问的原因。

计算机科学中的线程是进程内的实体，可以彼此独立地调度。进程中的线程共享进程范围的数据（文件描述符等），但也拥有自己的堆栈来存储自己的数据。有时需要特定于给定线程的进程范围的数据。想象一下正在执行的线程的名称或类似的东西。传统的 UNIX® 线程 API，pthreads 提供了一种通过 pthread_key_create(3)、pthread_setspecific(3) 和 pthread_getspecific(3) 来实现此目的，其中线程可以创建指向线程本地数据的键，并使用 pthread_getspecific(3) 或 pthread_getspecific(3) 来操作这些数据。您可以很容易地看出，这不是实现此目的最便捷的方式。因此，各种 C/C++ 编译器的生产商引入了一种更好的方法。他们定义了一个新的修饰符关键字 thread，用于指定变量是线程特定的。还开发了一种访问此类变量的新方法（至少在 i386 上）。pthreads 方法倾向于在用户空间中实现为一个简单的查找表。这种解决方案的性能不是很好。因此，新方法使用（在 i386 上）段寄存器来寻址存储 TLS 区域的段，因此实际访问线程变量只是将段寄存器附加到地址，从而通过它进行寻址。段寄存器通常是 %gs 和 %fs，充当段选择器。每个线程都有自己的区域来存储线程本地数据，并且必须在每次上下文切换时加载段。此方法非常快，并且几乎在整个 i386 UNIX® 世界中都使用。FreeBSD 和 Linux® 都实现了这种方法，并且它产生了非常好的结果。唯一的缺点是在每次上下文切换时都需要重新加载段，这可能会减慢上下文切换的速度。FreeBSD 试图通过为此仅使用 1 个段描述符来避免此开销，而 Linux® 使用 3 个。有趣的是，几乎没有任何东西使用超过 1 个描述符（只有 Wine 似乎使用 2 个），因此 Linux® 为上下文切换支付了不必要的代价。

i386 架构实现了所谓的段。段是对内存区域的描述。内存区域的基地址（底部）、末尾（顶部）、类型、保护等。可以使用段选择器寄存器（%cs、%ds、%ss、%es、%fs、%gs）访问段描述的内存。例如，假设我们有一个基地址为 0x1234 且长度的段，以及以下代码

这会将 %edx 寄存器的内容加载到内存位置 0x1244 中。某些段寄存器具有特殊用途，例如 %cs 用于代码段，%ss 用于堆栈段，但 %fs 和 %gs 通常未用。段存储在全局 GDT 表或本地 LDT 表中。LDT 通过 GDT 中的条目进行访问。LDT 可以存储更多类型的段。LDT 可以是每个进程的。这两个表最多定义 8191 个条目。

Linux® 中设置 TLS 的主要方法有两种。它可以在使用 clone 系统调用克隆进程时设置，也可以调用 set_thread_area。当进程将 CLONE_SETTLS 标志传递给 clone 时，内核期望 %esi 寄存器指向的内存为段的 Linux® 用户空间表示，该表示将转换为段的机器表示并加载到 GDT 插槽中。GDT 插槽可以使用数字指定，也可以使用 -1 表示系统本身应该选择第一个空闲插槽。在实践中，绝大多数程序只使用一个 TLS 条目，并且不关心条目的数量。我们在模拟中利用了这一点，并且实际上依赖于它。

线程需要某种同步机制，POSIX®提供了一些同步机制：互斥锁用于互斥，读写锁用于互斥，并带有读写操作的偏向比例，以及条件变量用于通知状态更改。有趣的是，POSIX®线程API缺乏对信号量的支持。这些同步例程的实现很大程度上取决于我们拥有的线程支持类型。在纯1:M（用户空间）模型中，实现可以在用户空间中完成，因此非常快（条件变量可能会最终使用信号实现，即不快）且简单。在1:1模型中，情况也很清楚——线程必须使用内核机制进行同步（这非常慢，因为必须执行系统调用）。混合M:N场景只是结合了第一种和第二种方法，或完全依赖于内核。线程同步是支持线程的编程的重要组成部分，其性能会极大地影响最终程序。FreeBSD操作系统上的最新基准测试表明，改进的sx_lock实现使ZFS（一个重量级的sx用户）的运行速度提高了40%，这是内核级的东西，但它清楚地表明了同步原语的性能有多么重要。

线程程序应尽可能减少锁的竞争。否则，线程只会等待锁，而不是执行有用的工作。因此，编写良好的线程程序很少出现锁竞争。

Linux®实现了1:1线程，即它必须使用内核同步原语。如前所述，编写良好的线程程序很少出现锁竞争。因此，一个典型的序列可以执行为两个原子增加/减少互斥锁引用计数器，这非常快，如下例所示。

1:1线程迫使我们对这些互斥锁调用执行两次系统调用，这非常慢。

Linux® 2.6实现的解决方案称为futex。Futex在用户空间实现对竞争的检查，仅在发生竞争时才调用内核原语。因此，典型情况无需任何内核干预即可发生。这使得同步原语的实现相当快速且灵活。

futex系统调用如下所示

在此示例中，uaddr是用户空间中互斥锁的地址，op是我们即将执行的操作，其他参数具有针对每个操作的含义。

Futex实现以下操作

FreeBSD中的futex仿真取自NetBSD，并由我们进一步扩展。它位于linux_futex.c和linux_futex.h文件中。futex结构如下所示

而结构waiting_proc是

在Linux® 2.6.16内核的开发过程中，添加了*at系统调用。这些系统调用（例如openat）的工作方式与其非at对应版本完全相同，除了dirfd参数略有不同。此参数更改了要执行系统调用的给定文件的位置。当filename参数为绝对路径时，将忽略dirfd，但当文件路径为相对路径时，它将发挥作用。dirfd参数是相对于其检查相对路径名的目录。dirfd参数是某个目录的文件描述符或AT_FDCWD。因此，例如，openat系统调用可以是这样的

此基础设施对于在工作目录外部打开文件时避免竞争条件是必要的。假设一个进程由两个线程组成，线程A和线程B。线程A发出open(./tmp/foo/bah., flags, mode)，并在返回之前被抢占，线程B运行。线程B不关心线程A的需求，并重命名或删除/tmp/foo/。我们遇到了竞争条件。为了避免这种情况，我们可以打开/tmp/foo并将其用作openat系统调用的dirfd。这还使用户能够实现每个线程的工作目录。

Linux® 系列的 *at 系统调用包含：linux_openat、linux_mkdirat、linux_mknodat、linux_fchownat、linux_futimesat、linux_fstatat64、linux_unlinkat、linux_renameat、linux_linkat、linux_symlinkat、linux_readlinkat、linux_fchmodat 和 linux_faccessat。所有这些都是使用修改后的 namei(9) 例程和简单的包装层实现的。

ioctl 接口由于其通用性而非常脆弱。我们必须记住，Linux® 和 FreeBSD 之间的设备有所不同，因此必须谨慎地进行 ioctl 模拟工作。ioctl 处理在 linux_ioctl.c 中实现，其中定义了 linux_ioctl 函数。此函数简单地遍历 ioctl 处理程序集以查找实现给定命令的处理程序。ioctl 系统调用有三个参数：文件描述符、命令和参数。命令是一个 16 位数字，理论上它被划分为高 8 位确定 ioctl 命令的类别，低 8 位是给定集中实际的命令。模拟利用了这种划分。我们为每个集合实现处理程序，例如 sound_handler 或 disk_handler。每个处理程序都定义了最大命令和最小命令，用于确定使用哪个处理程序。这种方法存在一些小问题，因为 Linux® 并不始终如一地使用集合划分，因此有时不同集合的 ioctl 会位于它们不应属于的集合中（例如，SCSI 通用 ioctl 位于 cdrom 集合中）。FreeBSD 目前没有实现许多 Linux® ioctl（例如，与 NetBSD 相比），但计划是从 NetBSD 移植这些 ioctl。趋势是在本机 FreeBSD 驱动程序中也使用 Linux® ioctl，因为应用程序的移植很容易。

每个系统调用都应该可以调试。为此，我们引入了一个小型基础设施。我们有 ldebug 功能，它指示是否应该调试给定的系统调用（可以通过 sysctl 设置）。对于打印，我们有 LMSG 和 ARGS 宏。这些用于更改可打印字符串以获得统一的调试消息。