第一幕：操作系统的黎明——从引导扇区到内核映像

当你指尖按下电源按钮的刹那，一股微弱的电流便沿着主板上的铜箔悄然蔓延，唤醒沉睡的硅芯片。这不是魔法，而是一场精密编排的电子芭蕾的开端——计算机，这台由人类智慧凝结的复杂机器，即将从纯粹的物理状态踏进逻辑与指令的王国。而操作系统，这个数字世界的“原生意识”，其诞生之旅的每一微秒都凝聚着 decades 的架构设计与工程权衡。我们的故事，就从这最原始、最关键的“第一推动”讲起：如何将一堆无序的电子信号，锻造成一个拥有自我认知、能够管理资源、运行程序的“生命体”。本章将带你潜入 x86 架构启动流程的最底层，以 Linux 内核为样本，解剖从 BIOS 固件到 `start_kernel()` 函数被调用的完整链条。我们将亲眼见证控制权如何在一系列严苛的“交接仪式”中传递，从 16 位实模式的混沌，一步步迈入 32/64 位保护模式的秩序，最终催生出那第一个拥有 PID 0 的“原初进程”——调度器自身的前身。这不仅是技术的解码，更是一次对“无中生有”这一计算哲学命题的深度求索。

---

**第一幕：权力的交接——从 BIOS 到引导加载程序**

计算机加电瞬间，CPU 复位，其内部指令指针寄存器（x86 的 `CS:IP`）被硬件强制初始化为一个众所周知的物理地址：`0xFFFF0`。这个地址位于主板 BIOS（基本输入输出系统）芯片的最高端，是固化在只读存储器中的第一段可执行代码的起点。此刻，CPU 运行在最原始的 16 位实模式 下。实模式是一个近乎“裸奔”的纪元：没有内存保护，没有虚拟地址，所有代码都以物理地址直接访问内存，且寻址空间被限制在 1MB 的“低端内存”范围内（通过段寄存器 `<< 4 + 偏移` 的方式形成 20 位地址总线）。BIOS 的首要使命，是完成对核心硬件（CPU、内存、显卡、键盘控制器等）的上电自检（POST），这是一系列严格的诊断测试，确保基础硬件没有致命故障。若检测失败，主板会通过蜂鸣器代码或屏幕显示警告，启动流程就此中断。

POST 通过后，BIOS 开始构建一个临时的、简化的运行时环境。它会探测并记录可用的系统内存量（通过调用 `INT 15h` 的 `E820` 功能等），初始化中断向量表（IVT，位于内存低端 `0x00000`-`0x003FF`），并设置一些关键硬件（如 8259 可编程中断控制器、8253/8254 定时器、DMA 控制器）的默认配置。这些工作，为后续更复杂的软件提供了一个最低限度的、可预测的硬件抽象层。接着，BIOS 将执行其最后一项、也是最具决定性的任务：寻找并执行引导设备。它按照 CMOS 配置中设定的顺序（如软盘、光驱、硬盘、USB），依次查询每个设备的第一个扇区（512 字节）。这个扇区，被称为引导扇区（Boot Sector），必须以其魔数 `0xAA55` 作为签名结尾，这是 BIOS 识别其有效性的唯一标准。一旦找到，BIOS 便将其加载到物理内存的固定位置 `0x7C00`，然后直接跳转到该地址，将控制权完全交出。

此刻，舞台中央的主角从固化硬件转向了存储在磁盘上的这 512 字节代码。它极其微小，却承载着加载整个操作系统的重任。在 Linux 的早期历史中，这个角色曾由 `bootsect.S`（引导扇区代码）扮演，它本身就是一个精巧的汇编程序。其核心逻辑可以概括为：

1. 自定位与栈设置：由于被 BIOS 加载到 `0x7C00`，代码需要计算自身加载地址，并设置一个安全的栈空间（通常设在 `0x7C00` 以下，避免覆盖自身）。 2. 加载下一阶段：引导扇区空间有限（仅 510 字节可用代码），无法完成复杂的内核加载。它的任务是读取磁盘上的下一个阶段——setup 模块——到内存的指定位置（如 `0x90200`）。在经典的 Linux 启动流程中，`bootsect.S` 会使用 BIOS 磁盘中断 `INT 13h`，以 CHS（柱面-磁头-扇区）或 LBA 方式，将紧随引导扇区之后的多个扇区（setup 代码）读入内存。 3. 跳转：读取完成后，`bootsect.S` 执行一个远跳转，将 CPU 控制权移交给 setup 模块的入口点。

这个过程，是操作系统获得“生命”的第一次呼吸。然而，`bootsect.S` 的时代在现代 Linux 中已渐成历史。随着硬盘容量突破 8GB 的 CHS 寻址限制，以及多系统引导的需求，更强大、更灵活的引导加载程序（Bootloader）如 LILO、GRUB（GRand Unified Bootloader）应运而生，并逐渐接管了这一职责。如今，在典型的 x86 PC 上，BIOS/UEFI 加载的通常是 GRUB 的第一阶段引导代码（Stage 1），它同样极小，驻留在 MBR（主引导记录）或 EFI 系统分区中。GRUB 的核心优势在于其多系统支持、配置文件驱动以及符合 Multiboot 规范（或 EFI 规范），使其能够以标准化方式加载各种符合规范的操作系统内核，而无需为每个内核编写定制加载器。

以 GRUB 2 为例，其 Stage 1 代码加载 Stage 1.5（如 `core.img`），后者包含必要的驱动（如用于识别 ext2/3/4、Btrfs、XFS 等文件系统的模块），从而能够读取 `/boot` 分区。最终，GRUB 根据其配置文件 `grub.cfg`，找到并加载 Linux 内核映像文件（通常为 `vmlinuz-<version>`）和初始 RAM 磁盘（initramfs，一个临时的根文件系统镜像）。Multiboot 规范定义了内核映像的格式和引导加载程序应提供的环境（如内存布局信息、命令行参数、模块列表等）。GRUB 将内核映像加载到内存的适当位置（传统上是 `0x100000`，即 1MB 以上，以避开实模式下可寻址的 640KB 常规内存区），将 initramfs 作为模块加载，然后跳转到内核的入口点——一个符合 Multiboot 规范的符号，通常是 `_start`。

至此，控制权正式从 BIOS/固件和引导加载程序，移交到了 Linux 内核自己手中。但此刻的内核，还只是一段被加载到内存的、压缩的二进制数据流，它自身尚未开始执行。真正的“觉醒”时刻，即将到来。

---

**第二幕：穿越模式的窄门——arch/x86/boot 目录下的秘密工坊**

当 CPU 跳转到内核入口点时，它仍然沉浸在 16 位实模式的“旧梦”中。而现代操作系统，尤其是 Linux，其内核主体代码是 32 位保护模式（对于 x86-64 则是 64 位长模式）的产物。保护模式提供了内存分段/分页保护、更大的地址空间（4GB 或更大）、特权级（ rings ）等核心机制，是构建多任务、安全隔离系统的基石。因此，内核启动过程中最惊险、最富技术张力的环节之一，便是从实模式到保护模式的切换。这段极其关键、又高度依赖硬件的代码，被精心地封装在 Linux 源码树的 `arch/x86/boot` 目录之下。它是一个与内核主体相对独立的“秘密工坊”，用汇编语言书写，负责完成所有“前戏”，为 `start_kernel()` 的优雅登场铺平道路。

让我们打开这个工坊的门。在典型的 Linux 源码（如 6.x 版本）中，`arch/x86/boot` 包含以下核心文件：

• **`bootsect.S`**：如前所述，在现代使用 GRUB 等高级引导加载程序时，此文件通常不再被直接使用，但其逻辑（如加载下一阶段）仍可被视作经典参考。在无引导加载程序的简单场景（如从软盘启动）或作为教学范例，它仍是起点。
• **`setup.S`**：这是本幕的**绝对核心**。它是一段 16/32 位混合的汇编代码，被引导加载程序（或 `bootsect.S`）加载到 `0x90200` 附近的内存位置。它的使命，是在实模式下运行，但为切换到保护模式做好一切准备。
• **`compressed/` 目录**：包含 `head.S`、`misc.c`、`piggyback.S` 等。`head.S` 是保护模式开启后，内核压缩代码解压后的**第一个 32 位入口点**。`piggyback.S` 负责将压缩的内核核心（`vmlinux.bin.gz` 等）与解压代码“粘合”在一起。
• **`video.S`, `apm.c`, `pm.c` 等**：提供视频模式切换、高级电源管理（APM）等辅助功能。

现在，聚焦 `setup.S` 的史诗级操作。我们可以将其任务分解为一系列环环相扣的步骤：

1. 环境检测与基本设置：代码首先通过 BIOS 中断（如 `INT 10h` 获取视频信息，`INT 13h` 确认磁盘参数，`INT 15h` 获取内存布局 `E820`）收集硬件信息。这些信息被填充到一个名为 `boot_params` 的关键结构体中（在 `arch/x86/include/asm/bootparam.h` 定义）。这个结构体是 BIOS 到内核的数据契约，它包含了内存图、EDD（Enhanced Disk Drive）信息、命令行参数指针等所有内核启动所需的基础数据。`setup.S` 还要设置一个临时的全局描述符表（GDT），这是保护模式分段机制的基石。它至少包含三个段描述符：空段、代码段、数据段。这些描述符的基地址被设置为 `0`，限长设为 `0xFFFFF`，从而形成所谓的“平坦模型”——即代码段和数据段都能覆盖整个 4GB 地址空间，这是现代操作系统使用分页进行内存管理前的必要铺垫。

2. 启用 A20 线：这是物理硬件的一个 notorious 历史包袱。原始的 IBM PC 地址总线只有 20 位（A0-A19），能寻址 1MB 内存。但为了兼容早期软件，当访问略高于 1MB 的地址（如 `0x100000`）时，地址线 A20 会被屏蔽，导致地址回绕到低端内存（`0x00000` + 偏移）。这被称为 A20 线屏蔽。若不解除，任何试图访问 1MB 以上内存的代码（如加载高地址内核）都会失败。`setup.S` 必须通过多种可能的方法（如键盘控制器法、BIOS 功能调用、芯片组快速 A20 切换）来激活 A20 线，使 21 位地址线（A20）生效，解锁完整的 1MB+ 内存空间。这一过程往往需要循环尝试和状态检测，是启动代码中一段充满硬件兼容性处理的“黑暗艺术”。

3. 安装临时 IDT 与 GDT：虽然 GDT 已在第一步建立，但此时 CPU 仍在实模式，分段机制以 16 位方式工作。`setup.S` 会将这个 GDT 的地址加载到 `GDTR` 寄存器，并同时设置一个临时的中断描述符表（IDT），其内容通常指向一些简单的、用于在模式切换期间处理潜在异常的“陷阱”例程，防止切换过程中发生不可恢复的故障。

4. 进入保护模式：这是整个切换的“扳机”时刻。`setup.S` 执行以下关键指令序列： ```assembly movl %cr0, %eax orl $0x1, %eax # 设置 CR0 寄存器的 PE (Protection Enable) 位 movl %eax, %cr0 ``` 仅此一条指令，便从硬件层面开启了保护模式。但此时 CPU 仍在执行之前的 16 位指令流，逻辑上处于一种“混合状态”。下一步，必须立即执行一个远跳转（far jump）来刷新 CPU 的指令预取队列，并强制 CPU 使用新的保护模式语义来解释后续指令： ```assembly ljmp $__BOOT_CS, $protected_mode_start ``` 这里，`__BOOT_CS` 是 GDT 中代码段选择子（如 `0x08`），`protected_mode_start` 是一个 32 位代码标签。这个跳转之后，CPU 才真正完全运行在 32 位保护模式下，段基址生效，寻址空间扩展，特权级机制激活。

5. 设置 32 位环境：跳转到 `protected_mode_start` 后，代码需要立即建立 32 位运行环境：更新段寄存器（`DS`, `ES`, `FS`, `GS`, `SS`）为数据段选择子，设置 32 位栈指针（`ESP`），并可能重新计算并加载一个更完善的 GDT（用于后续内核的平坦模型）。此时，实模式的“遗迹”已被彻底清除。

至此，`setup.S` 的历史使命完成。它通过一段精炼而脆弱的汇编代码，在物理内存的“荒野”中为内核主体搭建起一个符合保护模式规范的“临时营地”。接下来，它将控制权交给 `compressed/head.S`——这是压缩内核解压后的第一个 32 位 C 语言可调用的入口点。

---

**第三幕：解压与初啼——head.S 到 start_kernel() 的使命传递**

`compressed/head.S` 是连接“引导工坊”与“内核殿堂”的最后一节车厢。它本身也是用汇编写的，但其核心任务却是调用 C 函数来解压内核主体。在 `arch/x86/boot/compressed/` 目录下，`vmlinux`（未压缩的完整内核）在编译时会被一个压缩工具（如 `gzip`、`bzip2`、`LZMA` 或现代的 `zstd`）处理，生成一个压缩的二进制 blob。这个 blob 与一段小巧的解压例程（包含在 `head.S` 和 `misc.c` 中）链接在一起，形成最终的内核映像 `vmlinuz`（z 代表压缩）。`head.S` 的入口点，就是 GRUB 等引导加载程序跳转到的内核 Multiboot 入口。

`head.S` 的职责序列如下：

1. 清除 BSS 段：首先，它会将内核的 `.bss` 段（未初始化全局变量区域）清零。这是 C 语言环境的基本要求，确保所有静态变量初始值为零。 2. 设置栈与调用解压函数：它设置一个临时的内核栈（通常位于 `_end` 符号之后），然后调用 `decompress_kernel` 函数（来自 `misc.c`）。这个函数会识别压缩格式，将压缩的内核数据（位于内存的高地址处，由引导加载程序放置）解压到其链接时指定的链接地址（通常是 `0x1000000` 或更高，即 16MB 以上，以避开传统低端内存区域）。解压后的内核，即我们通常所说的 `vmlinux`，是一个完整的 ELF 可执行文件映像，包含所有已初始化的代码和数据段。 3. 跳转到内核主入口：解压完成后，`decompress_kernel` 会返回，`head.S` 随后执行一个跳转，前往内核的主入口点——一个名为 `start_kernel` 的 C 函数。这个函数，才是 Linux 内核真正意义上的“主函数”或“零号进程创建者”。

从 `start_kernel()` 开始，我们正式进入了内核的“世界”。这个函数的定义在 `init/main.c`，它是内核初始化序列的总指挥。其调用链长而复杂，但可以归纳为几个核心阶段：

• **架构相关初始化**：`startup_32()`（在 `arch/x86/kernel/head_64.S` 或 `head_32.S` 中）首先执行，完成更精细的 CPU 特性检测（如 CPUID）、页表初始化（开启分页）、设置 `__this_cpu` 变量等。此时，虚拟内存系统已就绪。
• **核心子系统初始化**：随后，`start_kernel()` 依次调用一系列关键初始化函数：
• `setup_arch()`：架构终极设置，解析 `boot_params`，初始化 `memblock` 内存分配器（早期物理内存管理），设置 `zone_sizes` 等。
• `mm_init()`：建立内核页表，初始化 `slab` 分配器、`vmalloc` 机制等。
• `sched_init()`：调度器初始化，创建**空闲任务**（idle task），即 **PID 0** 进程（也称 `swapper` 或 `idle`）。
• `rcu_init()`：读写锁（RCU）初始化。
• `init_irq()`：中断描述符表（IDT）最终安装，并注册默认中断处理程序。
• `time_init()`：初始化系统时钟（如 TSC、HPET）。
• `console_init()`：控制台初始化，以便内核可以输出信息。
• `init_modules()`：模块子系统初始化。
• **启动第一个内核线程**：在所有基础服务就绪后，`start_kernel()` 会创建两个至关重要的内核线程：

1. `kthreadd`（PID 2）：所有内核线程的祖先。 2. `kworker` 等：用于处理内核工作队列。

• **最后，启动用户空间 init**：`start_kernel()` 的最后一步，是尝试挂载根文件系统（`mount_root()`），然后通过 `run_init_process()` 尝试执行用户空间的第一个程序——通常是 `/sbin/init`。如果失败，则尝试一系列备选程序（如 `/bin/sh`）。**注意**：此时运行的 `/sbin/init` 进程，其 PID 是 1，是用户空间进程的始祖。而 PID 0 的 `swapper` 进程，在创建 PID 1 后，便进入 idle 循环，作为所有进程的“祖父”存在，永不退出。

---

**第四幕：PID 0 的诞生——swapper 进程，一切之始**

在 `sched_init()` 中创建的那个 `idle` 任务，就是 Linux 中独一无二的 PID 0 进程，其 `comm` 字段通常显示为 `swapper` 或 `idle`。理解 PID 0 是理解 Linux 进程模型的关键。

PID 0 不是一个普通的用户进程。它是一个静态分配的内核线程，其 `task_struct` 结构在编译时便已确定，位于内核数据段的特定位置。它没有用户空间内存映射（`mm` 指针为 `NULL`），永远运行在内核态。它的核心使命有两个：

1. 作为调度器的“底座”：在系统空闲时（即运行队列为空），CPU 会切换到 PID 0 执行，执行 `cpu_idle()` 函数，通常是一个简单的 `hlt` 指令循环，让 CPU 进入低功耗状态，直到下一个中断唤醒。它是每个 CPU 的最终守护者。 2. 作为进程家族的始祖：PID 0 在初始化期间，会通过 `kernel_thread()` 创建 PID 1（`