第1章：操作系统是什么？—— 从Linux启动看世界

想象一下，你是一位初来乍到的演员，站在一个巨大而昏暗的剧院后台。周围堆满了道具、服装和灯光设备，各种工匠忙得团团转。如果没有一个总指挥，舞台将陷入一片混乱：灯光该何时亮？演员何时上场？背景幕布怎么切换？这个总指挥，就是舞台经理（Stage Manager）。他手里拿着剧本（程序），协调着灯光师（I/O设备）、音控师（音频）、舞美（图形）以及所有演员（进程），确保每一幕都精确无误地呈现。在计算机世界里，操作系统（Operating System） 就是这个无所不在的舞台经理。它不直接参与表演（运行你的应用程序），却掌控着一切资源，让硬件和谐共舞，让程序员能专注于创作（写代码）而非与晶体管搏斗。

那么，这个至关重要的“舞台经理”是如何被召唤出来、又是如何一步步搭建起整个剧院的呢？答案就隐藏在每一次按下电源按钮的瞬间。让我们以 Linux 为例，跟随一段真实而精妙的启动旅程，见证操作系统如何从一片冰冷的硬件废墟中诞生、成长，并最终接管整个系统。这不仅是一次技术探险，更是一场关于秩序、抽象与控制的哲学思辨。

---

从加电到内核：Linux启动的六幕剧

计算机启动是一个层层递进、环环相扣的过程，每一步都依赖于前一步的完美交付。我们可以将其戏剧化为六幕：

1. 第一幕： BIOS/UEFI 的晨祷 —— 硬件的自检与唤醒 2. 第二幕： 引导加载器 的密令 —— 寻找并装载“舞台蓝图” 3. 第三幕： 内核 的破壳 —— 从汇编到C的华丽转身 4. 第四幕： `start_kernel()` 的奠基仪式 —— 系统核心组件的初始化 5. 第五幕： `init` 进程的诞生 —— 用户空间的“第一缕光” 6. 第六幕： 用户空间的黎明 —— 登录界面与shell的登场

下面，我们逐一拆解每一幕的幕后细节。

第一幕： BIOS/UEFI 的晨祷 —— 硬件的自检与唤醒

当你按下电源键，电流涌向主板，中央处理器（CPU） 的reset引脚被触发，CPU寄存器被清零，它开始从预设的物理地址（x86架构下通常是`0xFFFF0`）读取第一条指令。这个地址指向的，就是固化在只读存储器（ROM）里的基本输入输出系统（BIOS） 或其现代继任者统一可扩展固件接口（UEFI）。这一步，是硬件对世界的第一次呼唤。

BIOS/UEFI首先执行上电自检（POST, Power-On Self-Test）。它像一位严谨的剧院电工，逐一检查：

• **核心部件**：CPU、内存（通过内存读取/写入测试）、显卡。
• **关键外设**：键盘、鼠标、硬盘控制器。
• **设备枚举**：在传统BIOS中，它通过读取**互补金属氧化物半导体（CMOS）** 存储器中保存的配置（哪些设备是启动项，顺序如何），来构建一个可启动设备列表（如硬盘、光驱、U盘）。UEFI则更智能，拥有自己的驱动模型，能直接识别PCI设备。

如果POST发现致命错误（如内存损坏），通常会通过蜂鸣器报警或显示错误代码。若一切正常，BIOS/UEFI便会执行其最后、也是最关键的使命：寻找并执行引导加载器（Boot Loader）。

它根据CMOS/UEFI设置的启动顺序，依次检查每个设备的主引导记录（MBR, Master Boot Record） 或GUID分区表（GPT） 中的EFI系统分区（ESP）。第一个找到有效引导扇区的设备，其前512字节（MBR）或EFI应用文件（如`\EFI\BOOT\bootx64.efi`）将被载入内存的特定地址（如`0x7C00`），并跳转执行。这一跳转，是控制权从固件（Firmware）向软件的第一次移交。

> 双语术语墙 #1 > | 中文 | English | > |------|---------| > | 基本输入输出系统 | Basic Input/Output System (BIOS) | > | 统一可扩展固件接口 | Unified Extensible Firmware Interface (UEFI) | > | 上电自检 | Power-On Self-Test (POST) | > | 主引导记录 | Master Boot Record (MBR) | > | 引导加载器 | Boot Loader | > | 固件 | Firmware |

第二幕： 引导加载器 的密令 —— 寻找并装载“舞台蓝图”

被BIOS/UEFI唤醒的引导加载器（我们以最流行的GRUB 2为例）此刻正运行在实模式（Real Mode） 下——一个CPU为了兼容早期8086处理器而保留的、内存访问受限的16位模式。GRUB的任务艰巨：它在512字节的MBR空间里（或后续的核心镜像（Core Image））只包含了极其精简的代码，必须完成两件大事：加载自身更完整的第二阶段代码，以及加载Linux内核镜像。

GRUB的启动过程通常是多阶段的： 1. Stage 1：位于MBR，负责加载Stage 1.5（可能位于MBR之后的“间隙”或特定分区），因为它需要文件系统驱动来读取`/boot/grub`目录。 2. Stage 1.5 / Stage 2：包含文件系统驱动和更复杂的逻辑。此时GRUB呈现菜单界面（由`grub.cfg`配置），让你选择内核版本或 recovery 模式。 3. 加载内核：当你选择后，GRUB会：

• 从磁盘读取Linux内核文件（通常是`/boot/vmlinuz-<version>`，`z`代表压缩过的）。
• 读取**初始内存盘（initramfs）**，一个临时的小型根文件系统，用于加载内核启动所需的内核模块（如硬盘、文件系统驱动）。
• 将内核和initramfs解压到内存的特定位置。
• 设置**内核参数（Kernel Parameters）**，例如`root=/dev/sda2`（指定真正的根文件系统位置）、`quiet`（减少打印信息）、`init=/bin/bash`（覆盖默认init进程）。
• 最后，**跳转到内核的入口点**，将控制权完全交给Linux内核。此时，CPU可能仍处于实模式，内核的早期汇编代码会负责切换到**保护模式（Protected Mode）** 或**长模式（Long Mode，64位）**，开启内存分页，为进入现代操作系统世界铺平道路。

> 关键源码片段（概念性）： > ```c > // GRUB 的“思想”：加载并跳转 > // 伪代码，体现逻辑 > load_kernel("vmlinuz-5.4.0", load_addr); > load_initramfs("initramfs.img", load_addr + size); > set_boot_params(root_device, mem_size, cmdline); > jump_to_kernel(entry_point, boot_params); > ``` > 这一跳转，是控制权从“引导程序”向“操作系统内核”的正式移交。舞台经理，开始上岗。

第三幕： 内核 的破壳 —— 从汇编到C的华丽转身

Linux内核镜像（`vmlinuz`）本身是一个可执行链接格式（ELF） 文件，但它的入口点并非一个普通的C函数`main()`，而是一段高度架构相关的汇编代码。这是启动的“最原始阶段”，必须用最基础的指令来设置一个最基本的执行环境。

以x86_64架构为例，入口点通常位于`arch/x86/boot/header.S`和`arch/x86/kernel/head_64.S`。这段代码（常被称为引导头（Boot Header） 和解压入口（Decompressor Entry））会： 1. 检查CPU是否支持长模式（64位）。 2. 设置临时页表，将CPU从实模式切换到保护模式，再切换到长模式，并开启分页（Paging）。这是里程碑事件，从此CPU可以使用超过1MB的地址空间，并实现虚拟内存。 3. 清空`.bss`段（未初始化全局变量区域）。 4. 将内核的数据段（Data Segment）、代码段（Code Segment） 等寄存器指向正确位置。 5. 调用C语言世界的第一函数：`start_kernel()`。

这段汇编代码通常被放在内核镜像的最前面，并且被设计成可以被解压程序（`arch/x86/boot/compressed/head_64.S`中的`decompress_kernel`）直接执行。它像一个坚韧的“破壁者”，用最原始的指令凿开硬件的坚硬外壳，为更高级的C语言 runtime 创造一个可以呼吸的空间。

第四幕： `start_kernel()` 的奠基仪式 —— 系统核心组件的初始化

当控制权终于交接到`start_kernel()`（定义在`init/main.c`）时，我们才算真正进入了Linux内核的“心脏”。这个函数是内核C代码的起点，名字中的`__init`标记告诉编译器，这些初始化代码在启动完成后就可以丢弃，以节省宝贵的内存。

`start_kernel()` 的执行序列，就是操作系统舞台经理搭建各个“部门”的过程。让我们跟随它的脚步：

```c asmlinkage void __init start_kernel(void) { char * command_line; // 1. 架构相关初始化：设置页表、检测CPU特性、初始化陷阱门等 setup_arch(&command_line); // 2. 打印内核横幅（Linux version, etc.） // 3. 初始化内存管理：设置伙伴系统、slab分配器 mm_init(); // 4. 初始化调度器：设置运行队列、时钟中断 sched_init(); // 5. 初始化中断处理：设置IDT，注册默认处理器 irq_init(); // 6. 初始化时间子系统：设置时钟源、定时器 time_init(); // 7. 初始化控制台：早期打印（printk）的出口 console_init(); // 8. 初始化文件系统：挂载rootfs？不，先初始化VFS层 vfs_caches_init(); // 9. 初始化信号、进程间通信（IPC）等 // 10. 最后，也是最关键的一步：创建内核线程 rest_init(); // 这个函数会创建第一个内核线程：kthreadd，并fork出init进程 } ```

这个序列绝非随意排列。它遵循严格的依赖关系：没有内存管理（`mm_init`），进程无法创建；没有调度器（`sched_init`），CPU无法切换任务；没有中断（`irq_init`），时钟无法滴答，I/O无法响应。 `start_kernel()` 就像舞台经理在开幕前，逐一确认灯光、音响、幕布、演员通道都已就绪。

其中，`rest_init()` 是通往用户空间的“传送门”。它内部会调用： ```c kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES | CLONE_SIGHAND); // 创建PID=2的kthreadd，它是所有内核线程的祖先 pid = user_mode_thread(init, NULL, CLONE_FS); // 创建PID=1的init进程（实际是kernel_thread，但会execve） ``` 这里创建的`init`进程（或`systemd`，取决于配置）将是用户空间所有进程的始祖，其进程号（PID）永远是1。

第五幕： `init` 进程的诞生 —— 用户空间的“第一缕光”

`start_kernel()` 最终会调用`cpu_startup_entry()`进入空闲任务（`swapper`，PID=0）的循环，但在此之前，`rest_init()` 已经通过`kernel_thread()`创建了`init`进程（PID=1）。这个进程在内核看来还是一个内核线程，但它会通过`do_execve()` 加载并执行用户空间的程序，通常是 `/sbin/init`（或 `/etc/init`，或 `/bin/systemd` 等）。这个`execve`调用，标志着从纯粹的内核态向用户空间的第一次跨越。

`init`进程的使命是神圣的：初始化整个用户空间环境。它会： 1. 根据其配置文件（如SysV init的`/etc/inittab`，或systemd的单元文件）挂载所有文件系统（包括之前initramfs提供的驱动所依赖的磁盘分区）。 2. 启动系统服务（网络、打印、图形界面等）。 3. 创建终端（tty）并启动`getty`，等待用户登录。 4. adoption 孤儿进程：任何其父进程退出的进程，都会被`init`（PID=1）收养，确保不会有进程成为“孤儿”而无法被回收。

从此，系统从单线程的内核启动阶段，进入了多进程、多任务的繁荣用户空间时代。

第六幕： 用户空间的黎明 —— 登录界面与shell的登场

当`init`启动`getty`（或`login manager`如`gdm`、`lightdm`）后，终端或图形界面出现，等待用户输入。当你输入用户名和密码，`login`程序验证通过后，会`execve`一个shell（如`bash`、`zsh`）。Shell读取你的配置文件，显示提示符，等待命令。此时，你输入`ls`、`vim`或`firefox`，shell会`fork`出子进程，并通过`execve`加载这些程序。这些用户进程，都通过系统调用（如`fork`、`execve`、`open`、`read`、`write`）与内核进行交互，请求服务。

至此，从按下电源到看到登录提示符，完整的Linux启动链条闭环。操作系统这个“舞台经理”，已经就位， Ready for the show.

---

启动全景图：Mermaid 流程图

下面这张图概括了从加电到用户空间的完整数据流与控制流转移：

```mermaid graph TD A[加电 Power On] --> B[CPU 执行 BIOS/UEFI] B --> C[POST 硬件自检] C --> D{查找可引导设备} D -->|找到| E[读取 MBR / EFI 应用] E --> F[执行 引导加载器 Stage 1] F --> G[加载 Stage 1.5/2 & 配置文件] G --> H[显示 启动菜单] H --> I[用户选择 内核 & 参数] I --> J[加载 内核镜像 & initramfs] J --> K[跳转至 内核入口点] K --> L[汇编引导代码<br/>切换模式/分页] L --> M[调用 start_kernel()] M --> N[架构/内存/调度/中断等初始化] N --> O[创建 第一个内核线程 kthreadd] N --> P[创建 第一个用户空间进程 init] P --> Q[init 执行 /sbin/init] Q --> R[挂载 根文件系统] R --> S[启动 系统服务 & getty] S --> T[显示 登录界面] T --> U[用户登录] U --> V[启动 Shell] V --> W[用户执行命令] ```

---

哲学沉思：我们为什么需要内核？

看到这里，一个深刻的问题可能浮现：这一切都太复杂了！为什么不能让程序直接跑在硬件上，非要一个“内核”在中间插一手？

在早期计算机（如1940-50年代的ENIAC）时代，确实没有现代意义上的操作系统。程序员就是操作员，他们用物理开关或纸带输入程序，机器独占式地运行，直到出错或结束。这种方式在单任务、简单计算场景下可行，但面对现代需求，立刻暴露三大致命缺陷：

1. 硬件抽象缺失：程序与硬件“裸婚” 每个程序都必须直接操作特定的硬件寄存器、内存地址。如果你为Intel 8086写的程序，无法在Motorola 68000上运行。操作系统内核提供了硬件抽象层（HAL），通过统一的系统调用接口（System Call Interface） 向程序暴露一致的资源视图（如“打开一个文件”、“分配一段内存”），而将底层硬件差异屏蔽在内核内部。这就像演员只需要知道“上场”（`fork`），而不必关心舞台机械的具体构造。

2. 资源管理混乱：无政府的“资源争夺战” 如果没有内核，多个程序将直接争抢CPU、内存、磁盘、屏幕。一个程序可以随意写入其他程序的内存区域，导致崩溃；它可以霸占整个磁盘，让其他程序无法存取；它可以死循环，让整个系统瘫痪。内核是资源的唯一仲裁者，它通过调度器（Scheduler） 分配CPU时间片，通过内存管理器（Memory Manager） 分配虚拟地址空间，通过I/O调度器管理磁盘访问。它确立了“先占先得”但“公平分配”的游戏规则。

3. 安全与隔离屏障：用户态与内核态的分野 x86 CPU的特权级（Privilege Levels） rings 0-3，内核运行在最高特权级（Ring 0），可以直接访问所有硬件和执行特权指令。用户程序运行在低特权级（Ring 3），任何试图直接操作硬件（如读写CR3寄存器、访问I/O端口）或访问内核空间的指令都会触发异常（Exception），被内核捕获并通常以“段错误（Segmentation Fault）”终止程序。这堵“墙”是系统稳定的基石。没有它，一个程序的bug（如数组越界）可能覆盖内核数据，导致系统崩溃，甚至被恶意程序利用提权。

4. 多任务并发的魔术：从“单线程人生”到“平行宇宙” 物理CPU在任何时刻只能执行一条指令。内核通过上下文切换（Context Switch） —— 保存当前进程的寄存器状态、内存映射，加载下一个进程的状态 —— 制造出多个进程“同时”运行的假象。这需要内核在时钟中断的驱动下，精确地、公平地