coursebook：面向Linux内核的C语言系统编程实践指南

1. “coursebook”不是课表软件，而是系统编程教学项目的命名逻辑

第一次在 GitHub 上看到 coursebook 这个仓库名时，我也下意识以为是某门大学英语课的电子课表工具——毕竟“course”+“book”太像教务系统里的术语了。但点进去发现 README 第一行就写着：“A minimal, self-contained systems programming curriculum built around Linux kernel interfaces and C.” ——瞬间明白：这不是一个应用层工具，而是一套以动手写 C 代码为唯一路径、直抵 Linux 内核边界的学习载体。

这个命名本身就是一个教学隐喻。“book”在这里不是纸质教材，而是可编译、可调试、可单步跟踪的代码实体；“course”也不是排课表的时间序列，而是从用户态到内核态的一条技术动线：从 printf 调用开始，拆解 write() 系统调用，追踪 sys_write 入口，定位 vfs_write 流程，最终停在 page_cache_alloc 的内存分配现场。整本“book”的每一页，都是一段不超过 50 行的 C 文件，每个文件解决一个具体问题：比如 03-syscall-trace.c 用 ptrace 拦截子进程的 openat 调用并打印路径；07-page-fault.c 主动触发缺页异常，再通过 /proc/<pid>/maps 验证 mmap 区域的 PROT_NONE 属性是否生效。

为什么不用更直白的名字，比如 linux-kernel-labs 或 c-systems-programming-exercises？因为 coursebook 暗含三层设计意图：第一，强调渐进性——章节编号（01-init, 02-fork, 03-syscall）强制学习者按顺序推进，跳读会导致后续实验无法编译（比如 04-elf-parser.c 依赖 02-fork 中封装的 read_elf_header 工具函数）；第二，强调可验证性——每个 chapter 目录下必有 test.sh，运行后只输出 PASS 或具体失败行号，拒绝模糊的“基本功能正常”描述；第三，强调最小完备性——不引入任何第三方库，连 libelf 都被手动解析，所有 ELF header 字段、section header table 偏移、program header 的 p_vaddr 计算，全部用裸指针和位运算实现。这种命名不是为了好听，而是把教学哲学直接刻进项目 DNA。

提示：如果你在搜索“coursebook c语言”时跳出一堆“大学英语课表APP”，说明你正站在两个平行世界的交界处——一边是教务系统的 CRUD 开发，一边是操作系统内核的字节级操控。请立刻检查当前终端是否处于 ~/coursebook/chapter-05 目录下，执行 make clean && make。如果报错 undefined reference to 'sys_mmap'，恭喜你，已成功进入真实世界。

我最初尝试复现 06-syscall-table.c 时，在 Ubuntu 22.04 上卡了整整两天。原因很朴素：Linux 5.15 内核默认关闭了 CONFIG_KALLSYMS_ALL，导致 /proc/kallsyms 里 sys_call_table 符号被标记为 t（text）而非 T（global），dlsym(RTLD_DEFAULT, "sys_call_table") 返回 NULL。后来才发现作者在 chapter-06/notes.md 里用斜体写着：“This only works on kernels compiled with CONFIG_KALLSYMS_ALL=y. For production use, see kprobes instead.”——这种克制的提示风格，正是 coursebook 的典型特征：不手把手教你怎么改内核配置，而是让你自己 grep .config、翻 Kconfig 文档、理解 kallsyms 符号导出机制的底层逻辑。它拒绝做保姆，只提供足够锋利的解剖刀。

2. 从 hello.c 到 kernel-module.c：coursebook 的四阶能力跃迁模型

coursebook 的目录结构表面看是线性章节，实则暗藏一个隐式的能力坐标系。我把它的 12 个核心章节映射到四个技术维度上，形成一张可量化的成长地图：

这个模型的关键在于：每一阶都强制打破前一阶的抽象屏障。Level 1 的 malloc 是 libc 封装，Level 2 的 mmap 是系统调用裸调，Level 3 的 kmem_cache_alloc 是内核 API 直接调用，Level 4 的 copy_to_user 则要求你同时理解用户态虚拟地址和内核态线性地址的映射关系。最典型的例子是 09-signal-handling.c：它不满足于 signal(SIGINT, handler) 的简单注册，而是用 sigaltstack() 设置独立的信号栈，再通过 sigreturn() 系统调用手动恢复寄存器状态——这已经是在模拟内核 do_signal() 函数的行为。

我曾试图跳过 Level 3 直接写 12-char-device.c，结果在 copy_to_user() 处连续崩溃三次。第一次是传入用户态地址 0x7fffe8a21000 未做 access_ok() 检查，内核 panic；第二次是忘记在 ioctl 处理函数中加 mutex_lock()，并发访问导致设备缓冲区数据错乱；第三次最隐蔽：copy_to_user() 返回非零值时，我直接 return -EFAULT，但没重置 current->state = TASK_RUNNING，导致进程永远挂起。这些错误在 Level 1 和 Level 2 完全不会出现，因为 libc 和系统调用层帮你屏蔽了地址空间切换、锁竞争、进程状态机等细节。coursebook 的残酷之处在于：它不告诉你“应该怎么做”，而是让你在 core dump 里亲手摸到这些细节的棱角。

注意：coursebook 所有实验均要求在 x86_64 架构下运行，ARM64 或 RISC-V 用户需自行修改 struct user_regs_struct 中的寄存器名（如 rax → x0）。作者在 CONTRIBUTING.md 中明确写道：“Porting to other architectures is an exercise left to the reader.”——这不是推脱，而是把架构差异本身变成学习材料。当你为 03-syscall-trace.c 添加 ARM64 支持时，必须查阅 arch/arm64/include/uapi/asm/unistd.h，理解 __NR_write 和 __NR_writev 的编号差异，这比背诵 syscall table 有价值得多。

3. coursebook 的编译链：为什么坚持手写 Makefile 而非 CMake

在 coursebook 的根目录下，你找不到 CMakeLists.txt，只有 12 个 chapter-xx/Makefile 和一个顶层 Makefile。这种“复古”选择背后，是对构建过程透明性的极致追求。以 chapter-04/Makefile 为例：

这段代码看似简单，但每个参数都是教学设计的锚点：

• -static 强制静态链接，避免运行时依赖 libc.so.6 版本差异。当 elf-parser 在 Ubuntu 20.04 和 CentOS 7 上都能直接运行时，你才真正理解什么是“可移植二进制”；
• -O0 关闭优化，确保 gdb 单步调试时源码行与汇编指令严格对应。在 04-elf-parser.c 的 read_elf_header() 函数里，gdb 下 step 命令能逐行看到 e_ident[0] == 0x7f 的比较，而不是被优化成一条 cmpb 指令；
• -g 生成调试信息，但作者特意在 chapter-05/Makefile 中添加了 strip --strip-unneeded $(TARGET) 步骤，教你区分“调试符号”和“运行时符号”——前者用于 gdb，后者影响 dlopen 动态加载。

最体现功力的是 chapter-11/Makefile（内核模块编译）：

这里没有隐藏 Kbuild 的复杂性。当你执行 make 时，实际触发的是内核源码树下的 scripts/Makefile.build，它会自动识别 obj-m 变量，调用 gcc -D__KERNEL__ -I$(KERNELDIR)/include ... 编译 kmem_cache.c。作者甚至在 notes.md 中要求你手动执行 gcc -E -dM kmem_cache.c | grep -i "linux\|version"，观察内核头文件定义的宏（如 LINUX_VERSION_CODE=330752），理解 #ifdef LINUX_VERSION_CODE >= KERNEL_VERSION(5,10,0) 的预处理逻辑。

我踩过最大的坑是在 chapter-12 编译字符设备驱动时，make 报错 fatal error: linux/module.h: No such file or directory。排查发现是 KERNELDIR 指向 /lib/modules/5.15.0-101-generic/build，但该路径是符号链接，实际指向 /usr/src/linux-headers-5.15.0-101-generic，而 linux-headers 包未安装。解决方案不是 apt install linux-headers-$(uname -r)，而是先 ls -l /lib/modules/$(uname -r)/build 确认链接目标，再 dpkg -S $(readlink -f /lib/modules/$(uname -r)/build) 查包名——这个过程逼你理解 Linux 内核开发环境的分层结构：build 目录提供编译接口，source 目录提供完整源码，headers 包仅包含必要头文件。

提示：coursebook 的 Makefile 从不使用 $(wildcard *.c) 自动收集源文件，所有 SOURCES 必须显式列出。这是为了让你意识到：链接顺序决定符号解析结果。在 chapter-06/syscall-table.c 中，utils.c 必须放在 syscall-table.c 之后，否则 dlsym() 查找 sys_call_table 时，utils.o 中的 get_syscall_table() 函数会因 sys_call_table 符号未定义而链接失败。这种“反自动化”设计，恰恰是培养系统程序员肌肉记忆的关键。

4. coursebook 的调试哲学：用 gdb + strace + perf 构建三维观测体系

coursebook 不提供 IDE 配置指南，所有调试都基于命令行三件套：gdb 观察程序内部状态，strace 监控系统调用行为，perf 分析内核事件。这并非刻意复古，而是因为真正的系统问题永远横跨用户态、内核态、硬件层三个平面，单一工具必然失效。

以 chapter-07/page-fault.c 为例，其核心逻辑是：

调试这个实验需要三步协同：

1. gdb 定位用户态断点：gdb ./page-fault → break mmap → run → step 进入 memset，此时 info registers 显示 rdi 寄存器值即为 addr；
2. strace 捕获内核交互：strace -e trace=mmap,mprotect,brk ./page-fault，输出中会看到 mmap(NULL, 4096, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9a2c000000，紧接着 mprotect(0x7f9a2c000000, 4096, PROT_READ|PROT_WRITE) —— 这就是缺页异常处理函数 do_wp_page() 的工作痕迹；
3. perf 验证硬件事件：perf record -e page-faults ./page-fault → perf report，在火焰图中能看到 do_page_fault 函数占据 98% 的采样，且 page-faults 事件计数为 1。

这三步缺一不可。如果只用 gdb，你会看到 memset 执行成功，却不知背后发生了 mprotect 系统调用；如果只用 strace，你能看到 mprotect 调用，但无法确认 addr 的具体值；如果只用 perf，你能统计缺页次数，却不知触发条件。coursebook 的调试练习，本质是训练你建立跨层级因果链的能力。

我曾在 chapter-09/signal-handling.c 中遇到信号丢失问题：父进程 kill(child_pid, SIGUSR1) 后，子进程的信号处理器未执行。strace -p <child_pid> 显示 --- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=...} ---，证明信号已送达；gdb -p <child_pid> 中 info proc status 显示 SigQ: 0/127852，表示信号队列为空；但 cat /proc/<child_pid>/status | grep Sig 显示 SigQ: 1/127852。矛盾点在于：strace 和 /proc/pid/status 都显示信号已入队，但处理器未触发。最终用 perf record -e syscalls:sys_enter_rt_sigreturn ./signal-handling 发现：子进程在 rt_sigreturn 系统调用返回后，RIP 寄存器指向了错误的地址——原因是信号栈 sigaltstack 设置时，ss.ss_sp 指向的内存未对齐（x86_64 要求 16 字节对齐）。这个 bug 只有 perf 能暴露 rt_sigreturn 的返回上下文，gdb 和 strace 都无法触及。

注意：coursebook 要求所有 perf 实验必须用 sudo perf record -a 全局采集，而非 perf record -p <pid>。因为内核调度器可能将进程迁移到其他 CPU，局部采集会丢失关键事件。作者在 chapter-10/notes.md 中写道：“If you don’t see page-faults in perf report, check if your kernel has CONFIG_PERF_EVENTS enabled. It’s not enabled by default on some cloud VMs.”——这再次印证其核心理念：调试能力 = 对工具原理的理解深度 × 对系统配置的掌控粒度。

5. coursebook 的终极陷阱：当 printf 成为你的敌人

coursebook 最反直觉的设计，是主动禁用标准 I/O 库。在 chapter-01/init.c 中，第一行注释就写着：“No stdio.h. Use write() directly.” 整个项目中，printf、fprintf、sprintf 等函数被彻底禁止，所有输出必须通过 write(1, "hello\n", 6) 实现。这不是刁难，而是为了让你看清 C 标准库的“魔法”如何掩盖系统真相。

以字符串输出为例，printf("hello") 的执行路径是：

中间经过至少 5 层函数调用、缓冲区管理、格式化解析。而 write(1, "hello", 5) 是一条直接的系统调用，gdb 中 stepi 单步就能看到 syscall 指令触发 sys_write。当你在 chapter-02/fork.c 中用 write() 而非 printf() 时，会立即发现父子进程的输出顺序差异：printf 因为行缓冲（stdout 连接到终端时）会延迟输出，而 write 立即生效。这个差异在 fork() 后变得致命——父进程 printf("parent") 可能尚未刷新，fork() 就创建了子进程，导致子进程也继承了缓冲区中的 "parent" 字符串，最终输出重复内容。

更深层的陷阱在 chapter-04/elf-parser.c。该程序需要解析 ELF 文件的 e_shoff（section header table 偏移），这个值是 64 位整数（Elf64_Off 类型）。如果误用 printf("%d", e_shoff)，会因类型不匹配导致高位截断；而 write() 强制你手动转换：char buf[20]; int len = snprintf(buf, sizeof(buf), "%ld", (long)e_shoff); write(1, buf, len);。这个过程逼你理解 snprintf 的返回值是写入字符数（不含 \0），而非缓冲区长度，从而避免 write(1, buf, sizeof(buf)) 输出垃圾数据。

我曾为 chapter-08/vfs-layer.c 的 read() 返回值处理栽过大跟头。代码中：

但如果换成 printf("%s", buf)，当 read() 返回 3 字节 "abc" 时，buf[3] 是 \0，printf 正常；但若 read() 返回 0（EOF），buf[0] 仍是上次残留的 'a'，printf("%s", buf) 会一直输出直到遇到 \0，造成无限循环。write() 的显式长度控制，天然规避了此类 bug。

提示：coursebook 的 utils.c 中提供了一个极简的 print_int(int n) 函数，用递归和 write() 实现整数转字符串。它的核心逻辑是：

C 复制

1

void print_int(int n) {

2

if (n < 0) {

3

write(1, "-", 1);

4

n = -n;

5

}

6

if (n / 10) print_int(n / 10);

7

char c = '0' + (n % 10);

8

write(1, &c, 1);

9

}

这段代码的价值不在功能，而在于它强迫你思考：printf("%d", n) 的 10 行代码背后，是怎样的除法、取模、字符映射逻辑？当你亲手实现一次，atoi()、strtol() 的内部机制就不再是黑盒。

6. 从 coursebook 出发：如何构建属于自己的系统编程知识图谱

完成 coursebook 全部 12 个章节后，你手上握有的不是一份“已完成作业”，而是一张可生长的知识拓扑图。这张图的中心节点是 C 语言，向外辐射出四条主干：Linux 内核接口、系统调用机制、内存管理模型、并发原语实现。每条主干上，coursebook 的每个实验都是一个锚点，你可以沿着锚点延伸出自己的研究分支。

例如，chapter-06/syscall-table.c 的核心是 sys_call_table 符号解析，这自然引向：

• 内核符号导出机制：阅读 kernel/kallsyms.c，理解 kallsyms_expand_symbol() 如何解压符号名；
• 系统调用劫持方案：对比 kprobe、ftrace、eBPF 三种 hook 方式，kprobe 的 register_kprobe() 和 eBPF 的 bpf_program_load() 在性能和安全性上的权衡；
• 现代替代方案：seccomp-bpf 如何在用户态过滤系统调用，landlock 如何实现无特权的沙箱。

再如 chapter-10/rcu-list.c 的 RCU 链表操作，可延伸至：

• RCU 宽限期实现：synchronize_rcu() 如何通过 rcu_gp_init() 启动 grace period，rcu_gp_kthread() 内核线程如何协调 CPU 间状态；
• 内存屏障语义：rcu_dereference() 中的 smp_read_barrier_depends() 在 x86_64 和 ARM64 上的汇编差异；
• 实际应用场景：net/core/dev.c 中 dev_base_head 链表为何必须用 RCU，mm/mmap.c 中 mm_rb 红黑树为何用 rcu_read_lock() 保护。

我的实践路径是：以 coursebook 的每个 chapter-xx 目录为根，创建 my-extensions/ 子目录，存放自己的扩展代码。比如在 my-extensions/chapter-07 下，我实现了：

• page-fault-tracer.c：用 perf_event_open() 创建 PERF_COUNT_SW_PAGE_FAULTS 事件，实时统计进程缺页次数；
• swap-injector.c：mmap() 分配大内存后 mlock() 锁定，再 madvise(MADV_DONTNEED) 释放，强制触发 swap-in；
• hugepage-test.c：mmap() 时指定 MAP_HUGETLB，验证 HugeTLB 页面的分配效率。

这些扩展不是为了炫技，而是把 coursebook 的“单点知识”转化为“网状能力”。当你能独立写出 page-fault-tracer.c 时，你已掌握 perf_event_open() 的 fd 管理、mmap() 的 PROT_READ 权限控制、poll() 等待事件就绪等技能，这些能力在 chapter-07 原始实验中并未涉及，却自然生长于其知识土壤之上。

最后分享一个真实经验：我在 chapter-12/char-device.c 的基础上，用 ioctl 实现了一个简易的 procfs 替代品——/dev/coursebook_stats，读取时返回当前进程的 min_flt（minor page fault）和 maj_flt（major page fault）计数。实现过程中，我不得不深入 fs/proc/array.c 查看 task_stat() 函数如何填充 struct task_struct 的 min_flt 字段，再参考 drivers/tty/tty_io.c 的 tty_ioctl() 实现 ioctl 命令分发。这个过程让我真正理解：/proc 不是魔法，它只是内核提供的一个特殊文件系统接口，而 coursebook 的字符设备实验，正是通往这个接口的最近路径。

这套知识图谱的终极检验标准，不是能否通过 make test，而是当你看到新的技术问题时，能否快速定位到 coursebook 中对应的锚点，并从那里出发构建解决方案。比如最近遇到容器内存限制问题，我立刻想到 chapter-07 的 mincore() 和 chapter-11 的 kmem_cache，进而查阅 mm/memcontrol.c 中 mem_cgroup_charge() 的实现——这种条件反射式的知识调用，才是 coursebook 交付给你的真正资产。