Linux 内核：定义、职责、心智模型与结构

前置：进程、fd 与文件、线程、状态切换、权限与安全、页表。前五篇用 xv6 讲清了单个机制，这一篇把视角拉远，看一个真实的、生产级的内核整体是什么样子。

学习路线：OVERVIEW 的「主题地图」把每个 xv6 lab 对应到 Linux 的子系统和读码任务。

本篇的数字来自两处，都是 2026-10-09 实测的：

• 本机源码树 ~/repo/kernel-lab/linux：主线 v7.3-rc6（提交 47324d3a5b3a）。
• 本机正在运行的内核：Ubuntu 的 7.0.0-38-generic，x86-64，16 个逻辑 CPU，已经开机约 40 小时。

先猜再看（命令都在宿主机上跑）：

uname -srm; cat /proc/cmdline         # 我是哪个内核、开机时带了什么参数
lsmod | wc -l                          # 加载了多少个模块
ps -eo ppid,comm | awk '$1==2'         # 内核线程（kthreadd 的孩子）
grep -E '^(ctxt|processes)' /proc/stat # 开机以来的上下文切换次数、fork 次数
strace -c ls /etc > /dev/null          # 一个 ls 发了多少个系统调用

0. 一张总图

Linux 内核是一个常驻内存、以 CPU 最高特权级运行的大程序。它独占硬件，把硬件包装成进程、文件、地址空间、socket 这些抽象，通过约 390 个系统调用提供给用户程序；它本身不"主动运行"，而是被系统调用、异常、中断这三种事件唤起，再加上一批自己创建的内核线程做后台工作。

 ┌────────────────────────────── 用户空间（U 态 / ring 3）──────────────────────────────┐
 │  bash   python   nginx   systemd(pid 1)   ……         glibc / musl：把系统调用包成函数 │
 └──────────────────┬───────────────────────────────────────────────▲──────────────────┘
       系统调用（syscall / ecall）  缺页等异常                       │ 返回值、信号、数据
 ═══════════════════╪════════════ 特权级边界 ════════════════════════╪══════════════════
 ┌──────────────────▼───────────────────── 内核空间（S 态 / ring 0）──┴──────────────────┐
 │  系统调用入口：arch/x86/entry/  →  do_syscall_64()  →  sys_call_table[nr]             │
 │ ┌─────────────┬──────────────┬──────────────┬──────────────┬──────────────────────┐ │
 │ │ 进程 & 调度  │ 内存管理      │ VFS 文件系统  │ 网络栈        │ IPC、安全、时间、BPF…  │ │
 │ │ kernel/     │ mm/          │ fs/          │ net/         │ ipc/ security/ …      │ │
 │ └──────┬──────┴──────┬───────┴──────┬───────┴──────┬───────┴──────────────────────┘ │
 │        │       块设备层 block/   字符设备、TTY…    网络设备层                            │
 │ ┌──────▼─────────────▼──────────────▼──────────────▼─────────────────────────────┐  │
 │ │ 设备驱动 drivers/（源码的 69%）：NVMe、GPU、网卡、USB、Wi-Fi……                     │  │
 │ └────────────────────────────────────────┬─────────────────────────────────────┘  │
 │ 体系结构相关 arch/x86、arch/riscv：陷入入口、页表格式、上下文切换、中断控制器          │
 └───────────────────────────────────────────┼───────────────────────────────────────┘
               中断 ▲                         ▼ 读写设备寄存器、DMA
 ┌────────────────────────────────────── 硬件 ────────────────────────────────────────┐
 │  CPU（多核）   内存   磁盘   网卡   GPU   定时器   中断控制器                            │
 └───────────────────────────────────────────────────────────────────────────────────┘

1. 定义：从八个角度说"内核是什么"

同一个东西，站的位置不同，看到的样子就不同。

内核不是什么

• 不是"操作系统"的全部。 Linux 严格来说只是内核。你用的 Ubuntu = Linux 内核 + glibc + systemd + shell + 各种工具。Android 用的也是 Linux 内核，但用户空间完全不同。
• 不是 libc。 printf、malloc、fopen 是 C 库在用户态实现的，最后才落到 write、mmap、openat 这些系统调用上。
• （基本上）不是一个进程。 内核代码大多是"在某个进程的身份下"或"在中断里"执行的，没有一个叫"内核"的进程在排队等 CPU。例外是内核线程（第 3.2 节）。
• 不是 pid 1。 pid 1 是用户空间的 init（本机是 systemd），由内核启动的第一个用户进程。

2. 职责：内核替用户程序管哪些事

每一项职责都可以用同一组问题来看：给用户的抽象是什么、状态存在哪个结构里、代码在哪、xv6 里对应什么。

一句话：xv6 实现了前 8 行的最小版本，Linux 把每一行都做到了生产级，又加上了后 6 行。

3. 心智模型

单靠一个模型看不全。下面七个模型各回答一类问题，遇到新东西时挑合适的那个去套。

3.1 服务端模型：用户只拿得到句柄

（01 已经讲过，这里只总结。）

• 状态在内核里，用户手里只有编号：fd、pid、socket 都是。用户想改状态只能发请求。
• 每个请求内核都要校验：这个 fd 是不是你的、这个指针是不是你的内存（04）。
• 用它回答："用户程序能不能直接做 X？"答案几乎总是"不能，只能请内核做"。

3.2 事件驱动模型：内核什么时候在执行

内核没有自己的 main 循环。CPU 进入内核只有三种方式，外加内核自己创建的线程：

"能不能睡眠"是内核编程的第一条规矩。 睡眠就是让出 CPU 等别人唤醒；中断打断的是一个无关的进程，在里面睡眠就等于让无辜的进程替你等。所以中断处理程序只做最紧急的事（确认设备、拷走数据），剩下的推给"下半部"：

• 软中断（softirq）：中断返回前或在 ksoftirqd 线程里执行，网络收包主要靠它；
• 工作队列（workqueue）：交给 kworker 内核线程在进程上下文里做，可以睡眠。

本机实测：kthreadd（pid 2）下面有 246 个内核线程，其中 kworker 135 个；migration、ksoftirqd、cpuhp、idle_inject 各 16 个，每个 CPU 一个。

用这个模型回答："这段内核代码现在是替谁在跑？能不能调用会阻塞的函数？"

3.3 对象模型：内核是一堆带引用计数的对象

把内核看成一个内存里的数据库：表是各种结构体，系统调用是对它们的事务。

三条通用规律：

1. 对象之间用指针连成图，系统调用就是在图上走一条路。read(fd)：task_struct → files_struct → file → inode → page cache 里的 folio。
2. 共享就用引用计数：fork 后父子的 fd 指向同一个 struct file，引用计数变成 2。close 只是减 1，减到 0 才真正释放。xv6 的 filedup/fileclose 是同一个模式。
3. 对象有生命周期：分配、初始化、发布（让别人能找到）、使用、撤销、等所有人用完、释放。很多内核 bug（use-after-free、泄漏）就是这条链断了一环。

用它回答："这个状态存在哪？谁还在用它？什么时候能释放？"

3.4 面向对象的 C：函数指针表

内核用 C 写，却到处是"接口"和"多态"：一个结构体里装满函数指针，不同的实现填不同的函数。

追一次 read，就能看到多态在哪里发生：

read(fd, buf, n)                                   用户态
  └→ SYSCALL_DEFINE3(read, …)      fs/read_write.c:723
     └→ vfs_read()                 fs/read_write.c:554     公共逻辑：权限、偏移量
        └→ file->f_op->read_iter()                         ← 多态：按文件类型分派
           ├→ ext4_file_read_iter()    普通文件：查 page cache，没有就发块 I/O
           ├→ anon_pipe_read()         管道：从环形缓冲区拷
           └→ sock_read_iter()         socket：从接收队列拷

xv6 里同样的分派写成 fileread() 里的 if (f->type == FD_PIPE) … else if (f->type == FD_INODE) …（02）。Linux 把这个 if 换成了函数指针，于是新增一种文件类型不用改公共代码。"一切皆文件"在实现上就是这张表。

3.5 分层与"机制和策略分离"

数据从用户走到硬件，要穿过好几层，每一层只和上下邻居说话：

写文件：  write → VFS → ext4（文件块怎么排） → page cache → 块层（合并、排序 I/O） → NVMe 驱动 → 磁盘
发网络包：send  → socket → TCP（可靠、拥塞控制） → IP（路由） → 网络设备层（排队） → 网卡驱动 → 网卡

每层之间是第 3.4 节的函数指针接口，所以换一个文件系统、换一块网卡，上下层都不用动。

机制和策略分离是同一个思想的另一面：内核提供"怎么做"的机制，把"做哪个"的决定留成可替换的部分。

• 调度：切换上下文是机制；选哪个任务是策略（sched_class，现在甚至可以用 BPF 写，即 sched_ext）。
• 内存回收：换出页是机制；换哪页是策略（LRU 列表、swappiness）。
• 安全：LSM 钩子是机制；SELinux、AppArmor 是策略。
• 网络：收发包是机制；防火墙规则（netfilter / nftables）、拥塞控制算法（tcp_congestion_control）是策略。

3.6 缓存模型：内核是一个巨大的缓存管理器

很多内核内存其实是缓存，用来把慢的东西变快：

free -h 里的 buff/cache 就是这些。Linux 的做法是"空闲内存就是浪费的内存"：尽量都拿来当缓存，需要时再回收。用这个模型回答："为什么第二次读同一个文件快得多？""为什么 free 显示内存快满了，系统却不卡？"

3.7 并发模型：很多 CPU 同时在内核里

xv6 只有几个 CPU，用一把大锁也能凑合。Linux 要在几百个 CPU 上同时运行内核代码，并发是设计的核心：

抢占让问题更复杂：内核代码执行到一半也可能被换下 CPU。Linux 提供几种抢占模式（PREEMPT_NONE、VOLUNTARY、PREEMPT），实时补丁 PREEMPT_RT 在 6.12 进入主线，让几乎所有内核代码都可以被抢占，换取可预测的延迟。xv6 的 lock lab 是这一节的入门。

3.8 宏内核，但是模块化、可编程

Linux 是宏内核，但有两个方向在"软化"它：

• 可加载模块：驱动编译成 .ko，运行时 insmod / modprobe 加载。本机加载了 176 个。注意模块加载进来后和内核完全平等，并不更安全。
• eBPF：用户写的小程序经过验证器检查（不能死循环、不能越界访问）之后，挂到内核的钩子上运行：抓包、跟踪、安全策略，现在连调度器（sched_ext）都能写。这是"在宏内核里安全地运行扩展代码"。

4. 结构

4.1 源码树地图

v7.3-rc6，统计 .c .h .S .rs 文件：

几点观察：

• 驱动占了七成。 "Linux 内核"的大部分是在支持各种硬件。真正的"核心"（kernel/、mm/、fs/ 的公共部分、net/ 的核心、block/、ipc/、init/）只有几百万行。
• mm/ 只有 23 万行，却是最难的部分之一：代码密度高，并发细节多。
• 读 Linux 的现实策略：不要试图读完，只沿着一条路径读（第 7 节）。

4.2 一个进程在内核里长什么样

struct task_struct 的定义从 include/linux/sched.h:835 到 1995 行。按 03 线程 里"资源 + 执行流"的拆法归类：

关键差别：xv6 把资源直接放在 struct proc 里；Linux 放的是指向资源的指针，所以多个 task_struct 可以共享同一个 mm、files。clone() 的各个 CLONE_* 标志决定共享哪些、复制哪些：全复制就是进程，全共享就是线程（03 §4）。

4.3 开机：从第一条指令到 pid 1

4.4 构建与配置

• Kconfig：全树一共 22,655 个配置项（git ls-files | grep Kconfig）。make menuconfig 选择编进哪些功能，结果写进 .config。每一项可以是 y（编进内核）、m（编成模块）或不选。
  • 本机给 vng 编的测试内核只开了 1,668 个 =y、16 个 =m；发行版内核通常有几千个模块。
  • make tinyconfig 能编出最小的内核，make defconfig 是体系结构推荐的默认配置。
• 产物：vmlinux（未压缩的 ELF，调试和 gdb 用）、arch/x86/boot/bzImage（压缩后真正被引导的映像）、*.ko（模块）、System.map（符号表）。
• Kbuild：每个目录的 Makefile 只写 obj-$(CONFIG_FOO) += foo.o，配置项直接决定编不编。

5. 在本机观察运行中的内核

先猜，再运行（2026-10-09，Ubuntu 7.0.0-38-generic，开机约 40 小时）：

/proc 和 /sys 本身就是第 3.4 节的产物：它们不是磁盘上的文件，而是内核用 file_operations 现场生成的内容。读 /proc/stat 就是调用一个内核函数。

6. xv6 与 Linux 对照

xv6 的价值：每个机制都只有最本质的部分，几十行就能看全。所以读 Linux 时，先在 xv6 里找到对应的那几十行，把它当地图。

7. 开发模型与社区（为参与贡献准备）

发布节奏

• 每个版本大约 9 到 10 周：前 2 周是合并窗口，Linus 从各子系统维护者那里拉取新功能，然后发布 -rc1；之后每周一个 -rc，只修 bug，通常到 -rc7 或 -rc8，然后正式发布。
• 本机树里的实例：v7.1（2026-06-14）到 v7.2（2026-08-16），九周，16,418 个非合并提交、2,737 位作者；v7.2 到 v7.3-rc1 的合并窗口里进了 15,267 个提交。
• 稳定版（stable）把修复回移植到已发布版本；每年有一个版本被定为 LTS，维护好几年。Ubuntu 的 7.0.0-38 就是在 7.0 上叠加了发行版自己的补丁。

维护者层级

• 补丁不是直接给 Linus，而是先给子系统维护者，维护者收进自己的树，合并窗口时再由 Linus 拉取。
• MAINTAINERS 文件记录了每个文件归谁管：本机统计 3,321 个条目，状态分布是 Maintained 2,235、Supported 807（有公司付钱维护）、Orphan 145（没人管）。
• scripts/get_maintainer.pl 补丁文件 告诉你补丁该发给谁、抄送哪些邮件列表。

提交补丁

• 用邮件：git format-patch + git send-email 发到邮件列表，在 lore.kernel.org 上公开存档，评审意见也在邮件里来回。
• 提交前跑 scripts/checkpatch.pl 检查代码风格（Documentation/process/coding-style.rst）。
• Signed-off-by: 表示你签署了 DCO（Developer Certificate of Origin），声明你有权提交这段代码。
• 入门文档：Documentation/process/ 下从 1.Intro.rst 到 8.Conclusion.rst 的系列，submitting-patches.rst，howto.rst。

关于 AI 工具的规定

本机树里的 Documentation/process/coding-assistants.rst 和 generated-content.rst 规定：

• AI 不能加 Signed-off-by:。只有人能签署 DCO，提交者要审查所有 AI 生成的代码，并承担全部责任。
• 用了 AI 工具要加 Assisted-by: 标签，格式是 Assisted-by: LLM [工具1] [工具2]（工具指 coccinelle、sparse 这类分析工具）。
• 用 AI 找 bug 要走完整流程：先读完开发流程文档，尽量写出复现程序，再写修复并验证。
• 拼写修正、格式化、机械重命名这类琐碎工具不在规定范围内。

8. 怎么读这么大的代码

1. 从一个具体问题出发，只追一条路径。 比如"read() 怎么拿到文件数据"，沿着第 3.4 节那条调用链往下走，旁边的分支先不看。
2. 先找 xv6 的对应代码当地图（OVERVIEW 的主题地图里有每个 lab 的对照）。
3. 工具：
   • 在线交叉引用：elixir.bootlin.com，点一个符号就能看所有定义和引用；
   • 本地：make compile_commands.json（或 scripts/clang-tools/gen_compile_commands.py）之后用 clangd 跳转；
   • git log -p 文件、git blame：看一段代码为什么写成这样，提交说明往往比注释更有用。
4. 让它跑起来看：用 vng / QEMU 起本机编出的内核，gdb 加载 vmlinux 打断点；或者在宿主机上用 ftrace（/sys/kernel/tracing）、bpftrace、perf 观察真实调用（都需要 root）。
5. 读 Documentation/：每个子系统大多有设计文档，比如 Documentation/mm/、Documentation/scheduler/、Documentation/filesystems/vfs.rst。

9. 一张表

自测：不看笔记能不能做到

1. 从八个角度里挑三个，各用一句话说内核是什么。
2. 列出 CPU 进入内核的三种方式，并说出哪一种里不能睡眠、为什么。
3. 画出 read(fd) 从系统调用到具体文件系统的调用链，指出多态发生在哪一步。
4. fork 和 pthread_create 在 task_struct 层面的区别是什么？
5. 说出两个"机制和策略分离"的例子。

思考题（先自己答）

1. 中断处理程序为什么不能调用 mutex_lock()，却可以调用 spin_lock()？如果中断处理程序要拿的自旋锁，正好被它打断的那段代码拿着，会发生什么？内核用什么办法避免？
2. 本机有 135 个 kworker 线程，却只有 16 个 CPU。为什么需要这么多？
3. 一个可加载模块和编进内核的代码，在权限上有区别吗？那模块签名（CONFIG_MODULE_SIG）防的是什么？
4. eBPF 程序也在内核里运行，为什么它就"安全"，而模块不安全？验证器拒绝了哪些东西？
5. 为什么说 /proc/self/maps 里的每一行，对应的是内核里的一个 vm_area_struct，而不是一组页表项？两者的关系是什么？（提示：05 的懒分配。）
6. 微内核里一次 read() 文件大概要几次 IPC？宏内核里呢？