《Rust 下沉三部曲》第 3 篇 · 内核上篇 · Rust for Linux
有次编译新内核，我在 dmesg 里第一次看到这么一行：
[ 12.884] rust_minimal: Rust minimal sample (init)
那行字没什么特别的，跟周围其他内核日志长得一模一样。但它在告诉我一件挺离谱的事：这段逻辑不是 C 写的，是 Rust，而且此刻正跑在内核态、拿着 CPU 最高权限。
我盯着它看了几秒。这不是 demo，不是用户态里调个 FFI 的玩具——它是被内核模块加载器正经 insmod 进去、由内核直接调度的代码。
这一篇，我把这件事在 QEMU 里完整复现一遍，给你看每一步到底发生了什么。不是"理论上能跑"，是我自己确实跑通过的流程。中间有几个坑我踩过，你也大概率会踩，提前说清楚。
先泼掉一点浪漫主义：Rust 没有"取代" C
开搞之前得把预期摆正，不然你后面会困惑。
Linux 内核里的 Rust（社区叫 Rust for Linux，简称 RfL）不是用来重写调度器、内存管理、文件系统的。那些核心、跑了几十年、被无数双眼睛审过的 C 代码，短期内不会动。Rust 的角色很具体：写新的驱动和外设模块，尤其是历史上最容易出内存安全 bug 的那批。
为什么要引 Rust 进门？根子上是同一个老问题——内核的 bug 里，内存安全类（空指针解引用、use-after-free、越界写、数据竞争）长期占大头。微软和 Google 各自的内部统计都显示，这类问题最高能占到安全漏洞的七成。Rust 在编译期就把这一类失误挡在门外，内核社区看中的就是这点。
但 Rust 进内核也不是全员欢呼。C 那边不少 maintainer 对"多一门语言、多一套 toolchain、多一堆跨语言接口"是有顾虑的，前两年公开争论不少。所以现实是：C 是地基，Rust 是在地基上搭新房间，两个房间之间通过 FFI 边界相连。
看到没——又是 FFI。前两篇讲的 unsafe、#[repr(C)]、内存布局，在这里直接变成了内核模块和 C 核心之间那道"墙"。
它不是一个 cargo new 就能开始的活
在这里我要先给你打预防针，免得你照着网上那些"30 秒跑通"的教程撞墙。
你不能像写普通 Rust 程序那样 cargo new + cargo build。内核模块不归 cargo 管，它归内核自己的 Kbuild 系统管。Rust 代码是被 Kbuild 调用 rustc 编进 .ko 的，连 core、alloc 这两个最基础的库，都是 RfL 用内核指定的 rust-src 现场为内核目标重新编译的。
而且——版本是卡死的。不是"差不多就行"。你手上的 rustc、bindgen、clang 版本，必须精确匹配你编译的那个内核版本的要求。差一个小版本号，可能直接编不过，而且报错信息烂得你半天看不出原因。
怎么查？进内核源码树：
# 看官方对工具链的要求
cat Documentation/rust/quick-start.rst
# 让内核自己检查工具链齐不齐、版本对不对
make LLVM=1 rustavailable
输出 Rust is available! 才算过关。
我第一次就卡在这儿——系统 rustc 是 1.74，那个内核要 1.73，差一个 minor 就跪了。别硬刚，按文档用 rustup 切到它要的那个版本，然后一定记得装 rust-src 组件：
rustup component add rust-src
这是 RfL 重新编译 core/alloc 必须的，漏了这一步后面会报一堆找不到 core 的错，非常迷惑。
另外 RfL 强依赖 LLVM：Rust 后端是 LLVM，而且 bindgen 生成 C 头文件的 Rust 绑定时用的是 libclang。所以编译全程都得 make LLVM=1。
打开内核配置里的 Rust 支持：
CONFIG_RUST=y
想直接跑官方示例模块，再把示例打开：
CONFIG_SAMPLES=y
CONFIG_RUST_SAMPLES=y
然后正常编内核（首次编二三十分钟起步，去喝杯咖啡）：
make LLVM=1 -j$(nproc)
make LLVM=1 modules -j$(nproc)
Rust 是怎么被"塞"进内核的？
在讲代码之前你要先搞明白构建链，不然你永远觉得这玩意儿让你摸不着头脑。
- 1. bindgen 先跑。 内核构建时，
bindgen 读内核的 C 头文件，自动生成一份 Rust 绑定——把 struct module、printk 这些 C 符号包成一堆 unsafe 的 Rust 声明。这份生成物，就是 kernel crate 底下那些"unsafe 墙"的来源。 - 2.
kernel crate 给它套安全壳。 RfL 维护者在这层 unsafe 绑定之上写了 kernel crate：把裸指针、锁、分配器，包成带类型、带所有权的安全抽象（下一篇细讲）。你写模块时只跟这层打交道。 - 3. 你的
.rs 被 rustc 编成目标文件，和 kernel crate、生成的绑定一起，由 Kbuild 链进最终的 .ko。
所以是这么一层层叠上去的：
你的 hello_rust.rs
│ （只用到安全抽象）
▼
kernel crate （安全壳）
│ （底下是 unsafe）
▼
bindgen 生成的 C 绑定 （unsafe 墙）
│
▼
C 内核核心 （struct module / printk / ...）
记住这个分层，下一篇写字符设备驱动时，你会清楚自己到底在哪一层写代码。
代码：一个能加载的 Rust 模块
内核自带的 samples/rust/rust_minimal.rs 是最干净的 hello world。我们照着写一个自己的。最省事的方式，是把下面这段代码直接替换掉 samples/rust/rust_minimal.rs 的内容，或照着它往 samples/rust/Makefile 和 Kconfig 里加一条自己的条目：
// hello_rust.rs
use kernel::prelude::*;
module! {
type: HelloRust,
name: "hello_rust",
author: "你的名字",
description: "我的第一个 Rust 内核模块",
license: "GPL",
}
struct HelloRust;
impl kernel::Module for HelloRust {
fn init(_module: &'static ThisModule) -> Result<Self> {
pr_info!("Hello from Rust kernel module!\n");
Ok(HelloRust)
}
}
impl Drop for HelloRust {
fn drop(&mut self) {
pr_info!("Goodbye from Rust!\n");
}
}
这段代码看着少，但每一行都有讲究。我当初也是逐行抠才明白的：
- •
use kernel::prelude::*; 不是随便导的。kernel::prelude 是 RfL 给模块作者准备的"标准装备包"，把 Result、Error、ThisModule、Module、pr_info!、module! 这些最常碰的东西一次性带进来。内核里没有 std，连 println! 都没有，你能用的基础件都在 core/alloc 和 kernel crate 里，这个 prelude 就是它们的门面。 - •
module! 是全篇最关键的东西，它干的事远比"填元数据"多。展开之后，它其实替你生成了：一句话：module! 是你 Rust 代码和 C 加载器之间的"翻译官 + 入场券"。
- • 模块的 C 侧入口：通过
module_init! / module_exit! 宏造出 C ABI 的 init_module / cleanup_module 符号，这样内核的模块加载器（它自己是 C 写的）才认得你的 Rust 模块； - •
MODULE_LICENSE / MODULE_AUTHOR / MODULE_DESCRIPTION 这些 C 宏——所以 license: "GPL" 不是摆设：内核靠它判断你能不能调用那些标了 EXPORT_SYMBOL_GPL 的符号。非 GPL 模块去调 GPL-only 符号，会直接被拒绝加载； - • 一个
ThisModule 的引用，供下面的 init 使用。
- •
kernel::Module trait 是模块的生命周期契约。init 在 insmod 时由内核调用，_module: &'static ThisModule 就是当前这个模块的 struct module 指针（为什么 'static？因为模块不被卸载就一直活着）。返回 Ok(Self) 表示加载成功，内核把你的实例存起来。 - • 这里的
Result 是 core::result::Result<T, kernel::Error>。 注意那个 Error 不是标准库的，是 kernel::Error，本质包着一个负值的 errno（比如 -ENOMEM）。也就是说：内核里没有 panic 兜底，加载失败你就得老老实实返回 Err。这正好接上 FFI 篇那句"panic 不能乱飞进 C"——在内核里乱 panic，直接就是整机 oops。 - •
Drop 就是卸载时的清理。rmmod 触发它。你看，Rust 的所有权 / RAII 思维原封不动搬进了内核：不像 C 要在 module_exit 里手动一个个 kfree、一个个 unregister，你只要在 Drop 里写清理逻辑，卸载时自动跑。这层抽象是 RfL 最舒服的地方之一。 - •
pr_info! 是内核版 println!，底层是 printk，打进内核环形日志缓冲区，dmesg 能看。
在 QEMU 里把它跑起来
为什么是 QEMU 而不是你自己的机器？因为写内核模块，一个手滑 insmod 进去就可能 panic、死锁、直接把系统搞崩重启。在虚拟机里，崩了就重启虚拟机，宿主机啥事没有。拿日常用的电脑当试验场，属于拿生产环境练手，不值当。
跑起来有两条路：
省事路线（建议先走这条）：virtme-ng
virtme-ng（vng）能直接用你刚编好的内核启动一个虚拟机，还把宿主的文件系统挂进去当根，你几乎感觉不到在虚拟机里。编完内核后：
vng -b # 用当前源码树的内核构建
vng -r # 启动进虚拟机
进去之后 insmod 你的 .ko 就跟在真机一样。第一次跑通，走这条最省心。
手动路线：自己起 QEMU
想完全掌控，就编个 bzImage，配个最小 initramfs（busybox 静态编一份塞进 cpio 就行），然后：
qemu-system-x86_64 \
-kernel arch/x86/boot/bzImage \
-initrd rootfs.cpio.gz \
-nographic \
-append "console=ttyS0"
模块编成 .ko 后，把它打进 initramfs，启动、加载、看日志：
# 加载
$ insmod hello_rust.ko
# 看内核环形日志
$ dmesg | tail -3
[ 42.123456] hello_rust: loading out-of-tree module taints kernel.
[ 42.123457] hello_rust: Hello from Rust kernel module!
# 卸载（会触发 Drop）
$ rmmod hello_rust
$ dmesg | tail -1
[ 58.654321] hello_rust: Goodbye from Rust!
注意第一行 taints kernel——内核会给你记一笔"加载了树外模块"，这是正常提示，不是报错，别被吓到。当你看到 Hello from Rust kernel module! 跳出来，就成了：你写的 Rust，此刻运行在 Ring 0。
到这里，你脑子里的"Rust"得换个形状
我刚接触 RfL 时最别扭的一点：它根本不像平时写的 Rust。
没有 std，没有 main，没有 cargo run。你写的不是"程序"，是一个被内核在合适时机调用的"插件"。alloc 虽然在，但底层分配器是内核的 kmalloc，分配可能失败，所以 RfL 给你的是 KBox::try_new 这种会失败、要你显式处理的 API，而不是用户态 Box::new 那种"失败就 abort"。这套"分配可能失败、错误必须被接住"的纪律，跟 FFI 篇、跟后面裸机篇，是同一个模子刻出来的。
这也正是我把这三篇串成一条线的原因：FFI 教你跟 C 安全地握手，内核教你在一片没有 std、不能 panic 的领土上写 Rust，裸机则是把 std 也彻底拿掉。它们共享同一套底层直觉。
收个尾，预告下一篇
这一篇你实际跑通了：
- • Rust 在内核里到底扮演什么角色（写新驱动，不是取代 C），以及它和 C 核心之间那道 FFI 边界；
- • 为什么不能
cargo build、版本为什么卡死、工具链到底要哪些； - •
hello_rust.rs 每一行的真实含义，特别是 module! 宏背后替你生成了什么； - • 在 QEMU / virtme-ng 里把它
insmod / rmmod，并从 dmesg 里确认它真的跑在内核态。
hello 模块只是"能加载"。真功夫在下一步——你要开始碰内存、碰锁、碰设备寄存器了。
下一篇：《内核里的 unsafe 是怎么被"驯服"的？Rust 字符设备驱动实战》。我们手写一个可读写的 /dev/rustdev，用户态 cat / echo 直接打通，你会第一次体会到 RfL 那层"安全壳"到底长什么样、又为什么值得。
