内核 Rust 未来展望

1. 我们现在的位置（2025）

Rust 在 Linux 内核中的旅程始于 2022 年 12 月的 Linux 6.1。到 2025 年中期：

基础设施：稳健的内核 crate（rust/kernel/），覆盖同步、内存分配、错误处理、文件操作、任务管理等
首个重要驱动：Android Binder 驱动（4500 行 Rust，Linux 6.8）
GPU 驱动：Asahi Linux 的 Apple Silicon GPU 驱动大量使用 Rust
块设备驱动：rnull（Rust null block）作为块层 Rust 抽象的参考实现
网络抽象：socket 和网络基础设施的 Rust 封装正在开发中（rust/kernel/net.rs, Linux 6.9+）
架构支持：x86_64、aarch64（ARM64）、初步的 riscv64 和 loongarch
工具链改善：GCC Rust (gccrs) 开发中，rustc_codegen_gcc 进展中

📌 观点：Rust在内存安全方面确实有效，是重构Linux内核的重要工具。但要真正理解Linux内核和内存管理，C语言的学习仍然是基础。请参阅 C语言深化教程了解完整的C语言底层编程知识体系，以及 C语言教程: 进程与内存管理理解C语言中的内存管理挑战。

2. 即将到来的：更多子系统采用 Rust

2.1 网络子系统

网络是内核中最复杂的子系统之一。Rust 网络抽象的早期工作包括：

rust/kernel/net.rs（自 Linux 6.9 开始出现）：封装 struct socket 和相关操作
UDP/TCP 套接字抽象：允许 Rust 驱动创建和使用网络套接字
可能的 Rust 网络驱动：如简单的虚拟网络设备

网络子系统的 Rust 化面临的独特挑战：

复杂的 SKB（socket buffer）生命周期
NAPI（New API）轮询模型
零拷贝操作（XDP、AF_XDP）

2.2 文件系统

文件系统是另一个 Rust 可以产生巨大影响的领域，因为：

文件系统是数据完整性的关键
文件系统 bug 可能导致数据丢失
文件系统代码是”从用户空间读取数据并处理”的典型场景，是安全攻击的主要入口

活跃的项目：

bcachefs：Kent Overstreet 与 Rust for Linux 讨论了用 Rust 编写部分 bcachefs 代码的可能性
tarfs：Wedson Almeida Filho 概念验证的用 Rust 编写的只读文件系统，证明 Rust 文件系统在内核中是可行的
puzzlefs：用 Rust 编写的下一代容器文件系统（用户态，但验证了 Rust 文件系统设计）
Ext4/Btrfs Rust 封装：讨论为现有文件系统提供 Rust API 封装

2.3 GPU 驱动（DRM 子系统）

Asahi Linux GPU 驱动：已在使用 Rust 和内核 DRM Rust 抽象
Nova 驱动：社区正在开发用于较新 NVIDIA GPU 的 Rust DRM 驱动（基于 NVIDIA 的 GSP 固件）
Intel Xe 驱动：Intel 的新 GPU 驱动使用 Rust 辅助工具

DRM 子系统的 Rust 抽象（rust/kernel/drm/）提供：

GEM（Graphics Execution Manager）缓冲区管理
DRM 设备注册和文件操作
IOCTL 分发

2.4 其他潜在子系统

子系统	Rust 化潜力	原因
USB	中	复杂的设备状态机，安全性重要
I2C/SPI	中	相对简单，适合 Rust 抽象
NVMe	高	已有 Rust 实现原型
SCSI	中	大型子系统，渐进式
输入（Input）	高	HID 解析器安全性重要
加密（Crypto）	高	常量时间操作，安全性关键
BPF	中	BPF 验证器和 JIT 可以从 Rust 的安全性中受益
KVM	低	与硬件深度绑定，对 C/汇编依赖强

3. 技术挑战

3.1 alloc 在内核上下文中

内核环境与用户空间的环境不同，这给 alloc crate 带来挑战：

当前解决方案：

rust/alloc/ 包含 alloc crate 的一个分支，针对内核定制
自定义 #[global_allocator] 将分配转发到 kmalloc/kfree
大型分配（>PAGE_SIZE）使用 kvmalloc

待解决问题：

Vec::reserve 可能调用 realloc，而内核没有 krealloc 的稳定语义
String 的增长可能触发分配，需要 GFP 标志控制
集合类型的容量增长策略需要适配内核内存压力环境

长期方案：

可能在内核中实现 collections crate 的完整替代品，而非复用标准 alloc
或扩展 alloc crate 使其更灵活（与上游 Rust 项目协调）

3.2 内核内存模型（LKMM）

Linux 内核内存模型（LKMM）定义了多核系统上的内存排序保证。Rust 的内存模型基于 C++ 内存模型，两者在细节上有差异。

具体问题：

LKMM 使用 READ_ONCE/WRITE_ONCE 宏，而 Rust 使用 Atomic* 类型
LKMM 有特定的”地址依赖排序”（address dependency ordering），RCU 依赖此特性
Rust 的 Ordering::Consume 几乎未被使用，而内核大量使用类似语义

进展：

内核 Rust 的 sync 模块封装了内核的原子操作
Arc 基于 kref 而非 Rust 的 Arc（即 alloc::sync::Arc 不使用）
与 LKMM 维护者（Paul McKenney 等人）正在进行讨论

3.3 架构支持

架构	支持状态	说明
x86_64	完善	主要开发平台
aarch64 (ARM64)	完善	第二主要平台（Android、服务器）
riscv64	初步	rustc 支持，内核适配进行中
loongarch	初步	中国龙芯架构
arm (32-bit)	部分	面临 LLVM 支持限制
powerpc	实验	ppc64le 有 LLVM 支持
m68k	无计划	LLVM 不支持
alpha	无计划	LLVM 不支持

关键瓶颈：

LLVM 后端对某些架构的支持不足
GCC Rust (gccrs) 可以解决 GCC-only 架构的问题，但仍在开发中
内核中对架构特定功能的 Rust 封装工作量

3.4 nightly 特性依赖

内核 Rust 依赖多个 nightly-only 特性，这带来挑战：

// 内核实际使用的 nightly 特性（位于 rust/kernel/lib.rs）
#![feature(new_uninit)]           // Box::new_uninit
#![feature(allocator_api)]        // 自定义分配器的完整支持
#![feature(pin_macro)]            // pin! 宏
#![feature(arbitrary_self_types)] // 自定义 self 类型
#![feature(coerce_unsized)]      // Unsized 强制转换
#![feature(dispatch_from_dyn)]   // 动态分发
#![feature(receiver_trait)]      // 接收者 trait
#![feature(unsize)]              // Unsize trait
#![feature(offset_of)]           // offset_of! 宏
#![feature(ptr_metadata)]        // 指针元数据
#![feature(inline_const)]       // 内联常量
// ... 约 20 个特性

为什么需要 nightly：

这些特性是 Rust 语言设计的实验性部分
其中一些（如 allocator_api）已经讨论了 5+ 年
内核团队与 Rust 语言团队合作推动这些特性的稳定化

进展：

new_uninit 在 1.75 稳定
offset_of 在 1.77 稳定
allocator_api 在 1.76 有进展但仍未完全稳定
目标是减少 nightly 特性依赖到最少

3.5 正常化（stabilization）路线图

内核团队与 Rust 语言团队正在合作。短期目标（1-2 年）：

稳定化优先级（高到低）：
1. allocator_api       -- 最关键的阻塞项
2. arbitrary_self_types -- 对内核 API 设计影响大
3. pin_macro           -- 内核初始化依赖
4. dispatch_from_dyn   -- 动态分发支持

4. 社区挑战

4.1 C 内核开发者学习 Rust

这是最大的社区挑战之一。大多数内核维护者有几十年 C 经验，他们的 C 代码审查直觉很难直接转化为 Rust。

学习曲线问题：

Rust 的所有权和借用需要”重新学习编程”
内核 Rust 有额外的 no_std 限制和内核特定抽象
需要同时理解 C 内核 API 和 Rust 封装

帮助方案：

文档：Documentation/rust/ 继续完善
培训：Linux Foundation 提供 Rust 内核开发培训
结对编程：Rust 开发者与 C 维护者合作写代码
渐进式学习：从阅读 Rust 抽象开始，再写代码

4.2 维护两套 API

当内核的 C API 改变时，Rust 封装必须同步更新。这产生了维护成本。

缓解策略：

bindgen 自动生成绑定（减少手动同步）
抽象层设计为”薄封装”（减少与 C API 的距离）
C API 的变更通常已经需要更新所有调用点（C 和 Rust 都需要更新）
CI 系统检查绑定是否与 C 头文件一致

4.3 代码审查容量

Rust 代码的审查需要同时理解 Rust 和内核子系统。目前符合条件的人数有限。

当前审查者（双向能力）：

姓名	熟悉子系统	状态
Miguel Ojeda	Rust 基础设施	主维护者
Alice Ryhl	Binder/Android	主动
Andreas Hindborg	块设备/NVMe	主动
Wedson Almeida Filho	文件系统/DRM	已转至 Microsoft
Danilo Krummrich	DRM/GPU	主动
Asahi Lina	Apple GPU	主动

扩展审查能力的方案：

培训现有子系统维护者（Greg KH 已开始审查 Rust 代码）
招募有内核经验的 Rust 开发者
使用自动化工具辅助审查（clippy、静态分析）

4.4 避免”Rust vs C”的宗教战争

内核社区历史上对语言选择比较务实。但”Rust vs C”仍然可能引起争议。

维护和谐的策略：

强调 Rust 是补充而非替代 C
用数据说话：CVE 数量、性能基准、代码行数比较
尊重 C 维护者的经验：他们了解子系统的复杂性
Rust 代码必须达到与 C 代码相同的质量标准
避免”Rust 比 C 好”的说法，而是”Rust 在某些场景下有助于减少安全漏洞”

5. 宏伟愿景：第一个安全的 OS 内核

5.1 这意味着什么？

如果 Linux 成为第一个在主线内核中广泛使用内存安全语言的通用操作系统，其影响将超越技术层面：

安全性的范式转移：从”打补丁修复漏洞”变为”设计时消除漏洞类别”
行业影响：如果 Linux 可以做到，Windows、macOS 和其他操作系统将面临采用内存安全语言的压力
经济价值：减少安全漏洞的经济损失（估计每年数十亿美元）
开发效率：减少调试内存安全 bug 的时间

5.2 与 seL4 的对比

seL4 是已知的第一个经过形式化验证（formal verification）的 OS 微内核。seL4 使用形式化方法证明 C 代码的正确性（无缓冲区溢出、无空指针等）。

Rust for Linux 采用不同策略：

seL4：形式化验证（完成后证明正确）= 高成本，低覆盖面
Rust for Linux：编译时类型检查（写代码时证明安全）= 低成本，覆盖面广

两者不是竞争关系而是互补的：

Rust 提供”日常安全”（所有代码路径的类型安全）
形式化验证提供”极端安全”（关键安全属性的数学证明）

5.3 时间线预测（推测性）

2025-2026：
  - Rust Binder 驱动稳定和优化
  - 首个 Rust 网络驱动（虚拟设备）
  - DRM Rust 抽象成熟
  - allocator_api 稳定化

2026-2027：
  - 更多生产环境 Rust 驱动（NVMe、input、I2C）
  - 首个 Rust 文件系统（只读）
  - GCC Rust 达到可用状态
  - 架构支持扩展到 riscv64 和 ppc64le

2027-2028：
  - Rust 成为新驱动的事实标准（在内核社区共识下）
  - 首个 Rust 写的可写文件系统
  - nightly 特性依赖减少到 < 5 个
  - 主流发行版默认启用 Rust 内核模块

2028-2030：
  - Linux 成为首个在主线中广泛使用内存安全语言的通用 OS 内核
  - 统计学上可测量：内核 CVE 数量显著下降
  - Rust 在至少 5 个主要子系统中使用

注意：这只是推测。内核开发受许多不可预测因素影响。但历史趋势（内存安全语言在系统编程中的兴起）是明确的。

6. 如何成为这个历史转变的一部分

6.1 现在应该培养的具体技能

不仅仅是 Rust，而是以下组合：

内核内部知识：

内存管理（MM）：page allocator、slab、kmalloc、vmalloc、mmap
调度器：CFS、实时、cgroup
中断处理：top half / bottom half、softirq、tasklet、workqueue
锁和同步：spinlock、mutex、RCU、seqlock、completion
设备模型：bus、driver、device、platform_device、device tree
文件系统：VFS 层、inode、dentry、superblock

系统编程基础：

指针和内存布局（size、alignment、padding）
并发和并行（多核、缓存一致性、内存屏障）
I/O 模型（MMIO、PMIO、DMA）
汇编（至少能阅读 x86_64 汇编）

工具和流程：

QEMU 和交叉编译
ftrace、perf、eBPF 跟踪
KASAN、KMSAN、UBSAN 调试
内核 printk 调试和 dmesg 分析

6.2 你现在就可以做的事情（今天）

# 今天就做这 5 件事：
# 1. 克隆内核源码
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
# 2. 编译一个最小内核
cd linux
make LLVM=1 defconfig
make LLVM=1 -j$(nproc)
 
# 3. 阅读 Rust 示例
cat samples/rust/rust_minimal.rs
cat rust/kernel/prelude.rs
 
# 4. 订阅邮件列表
# 发送邮件到 rust-for-linux+subscribe@vger.kernel.org
 
# 5. 加入 Zulip
# 打开 https://rust-for-linux.zulipchat.com

6.3 学习资源清单

资源类型	名称	链接/位置
书	Linux Device Drivers, 3rd Edition	lwn.net/Kernel/LDD3/
书	Understanding the Linux Kernel	O’Reilly
书	Linux Kernel Development (Robert Love)	入门友好
在线	Linux Kernel Module Programming Guide	sysprog21.github.io/lkmpg/
在线	Rust for Linux Documentation	内核源码 Documentation/rust/
邮件	LWN.net 内核文章	lwn.net/Kernel/
视频	Linux Plumbers Conference talks	搜索 YouTube
代码	内核源码中的 Rust 部分	linux/rust/

6.4 寻找导师

Zulip：在 rust-for-linux Zulip 上自我介绍并说明你想学习的方向
邮件列表：在发送补丁时表现出认真和耐心，审查者可能成为非正式导师
Kangrejos：参加 Rust for Linux 的年度聚会，面对面建立关系
贡献模式：持续贡献小补丁，展示可靠性

7. 更广阔的视角：Rust 在系统编程中的兴起

7.1 内核之外的 Rust 系统编程

内核 Rust 只是更大趋势的一部分：

固件：嵌入式 Rust（使用 RTIC、embassy 框架）
hypervisor：如 Cloud Hypervisor（用 Rust 写的 VMM，用于 AWS Nitro）
TEE/安全飞地：可信执行环境的 Rust 实现
引导加载器：如 oreboot（coreboot 的 Rust 替代品）
微控制器：Rust 在 ARM Cortex-M 上的广泛应用

7.2 Rust 在基础设施软件中的采用

项目	类型	状态
Linux 内核	OS 内核	测试阶段，首个驱动合并
Windows 内核	OS 内核	微软在 Windows 内核中使用 Rust（如 GDI 字体解析）
Android	移动 OS	Binder 驱动重写，更多组件计划中
AWS Nitro	Hypervisor	Rust VMM 用于生产
systemd	Init 系统	讨论中
QEMU	仿真器	部分 Rust 组件（vhost-user）
sudo/su	安全工具	Rust 替代品（sudo-rs）
curl	网络库	Rust 后端 (hyper)

7.3 为什么这个趋势不可逆

内存安全漏洞的经济成本太高：

每年因内存安全漏洞导致的直接损失估计在数十亿美元
每个 CVE 的内核漏洞修复成本（从发现到部署）估计在 $50, 000 -$ 100,000
政府法规开始要求”设计安全”（Secure by Design）— 美国 CISA、欧盟 Cyber Resilience Act
行业巨头（Google、微软）公开承诺在新项目中使用内存安全语言

这一趋势意味着：今天学习内核 Rust 开发的人将成为明天最重要的系统开发者。

8. 结束语

8.1 不仅是学习一门语言

学习内核 Rust 开发不仅是学习一门编程语言。它意味着：

学习操作系统内核：地球上最复杂的软件系统之一
学习安全编程：理解为什么代码不安全以及如何使其安全
学习开源协作：与数百名全球开发者合作
学习工程纪律：内核代码的质量要求会改变你对软件的期望

8.2 这是一次历史性的机遇

Linux 内核正站在十字路口。C 已经服务了 30 多年，但它对内存安全漏洞的脆弱性变得不可接受。Rust 提供了第一条可行的替代路径。

互联网历史上第一次，有可能构建一个现代通用操作系统内核，其大部分代码在编译时就保证了内存安全和线程安全。

而你正处在这一切发生的时刻。

8.3 你的第一步

今天：
  git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  cd linux
  cat samples/rust/rust_minimal.rs
  make LLVM=1 rustavailable

本周：
  订阅 rust-for-linux@vger.kernel.org
  阅读 Documentation/rust/quick-start.rst
  编译一个启用了 Rust 的内核

本月：
  编写你的第一个 Rust 内核模块
  在 QEMU 中测试
  找到第一个文档修复并提交补丁

今年：
  成为 Rust for Linux 的常规贡献者
  在邮件列表上建立存在
  参加一次内核会议

05-参与内核Rust开发 | 01-Linux内核Rust支持概述 | 10-嵌入式与no_std企业应用

章节考查（100分）

1. 选择题（20分，每题5分）

1.1 以下哪个架构目前对内核 Rust 支持最完善？

答案

x86_64（主要开发平台）和 aarch64/ARM64（第二主要平台）。

1.2 内核 Rust 依赖的 nightly 特性中，哪一项是最关键的阻塞项？

答案

`allocator_api`——它允许内核注册自定义的全局分配器（将 Rust 分配转发到 kmalloc/kfree），是内核 Rust 基础设施的核心依赖。

1.3 以下哪个项目是 Rust 写的文件系统概念验证？

答案

tarfs（Wedson Almeida Filho 的概念验证只读文件系统，证明 Rust 可以在内核中实现文件系统）。

1.4 为什么 GCC Rust (gccrs) 对内核 Rust 的未来重要？

答案

它允许在 LLVM 不支持的架构上（如 m68k、alpha）使用 Rust。某些架构由 GCC 独家支持，如果没有 gccrs，这些架构将永远无法使用内核 Rust。

2. 简答题（40分，每题10分）

2.1 描述 alloc crate 在内核环境中的挑战，以及为什么不能直接使用标准 alloc crate。

答案

挑战包括： 1. **无操作系统支持**：标准 `alloc` 假设有操作系统提供内存，内核需要自定义分配器 2. **GFP 标志**：内核分配需要 GFP 标志（GFP_KERNEL、GFP_ATOMIC 等），标准 `alloc` 的 API 不支持 3. **realloc 问题**：内核的 `krealloc` 语义与 `realloc` 不完全相同 4. **内存压力**：内核在内存压力下的行为不同，集合类型的增长策略需要适配 5. **大分配**：大分配（>PAGE_SIZE）在内核中使用 `kvmalloc` 而非 `kmalloc`

解决方案：内核使用 rust/alloc/ 中的 alloc crate 分支，通过自定义 #[global_allocator] 将分配转发到内核分配器，对大型分配使用 kvmalloc。

2.2 LKMM（Linux 内核内存模型）与 Rust 内存模型的差异创建了什么挑战？

答案

1. **原子操作接口不同**：LKMM 使用 READ_ONCE/WRITE_ONCE 宏，Rust 使用 Atomic* 类型和 Ordering 枚举 2. **Consume 排序**：LKMM 中 RCU 大量使用"地址依赖排序"（类似 Ordering::Consume），而 Rust 中 Ordering::Consume 几乎不被使用且语义模糊 3. **自定义原子类型**：内核有特殊的原子类型（如 atomic_t），需要专门封装 4. **内存屏障**：内核使用 mb()/rmb()/wmb() 宏，Rust 使用 atomic::fence()

应对方案：

内核 Rust 的 sync 模块封装内核的原子操作，不直接使用 core::sync::atomic
Arc 基于 kref（内核的引用计数）而非 Rust 标准库的 Arc
正在与 LKMM 维护者协调

2.3 分析”代码审查容量”问题。为什么 Rust 内核代码的审查者很少？如何扩大审查者群体？

答案

**为什么审查者少**： 1. **双重专业门槛**：审查者需要同时精通 Rust 和特定内核子系统 2. **稀有技能组合**：大多数 Rust 专家没有内核经验，大多数内核专家不熟悉 Rust 3. **时间竞争**：现有的内核维护者已经超负荷审查 C 代码 4. **学习成本**：即使经验丰富的开发者也需要 6-12 个月才能胜任审查

扩大审查者群体的策略：

培训现有 C 维护者（Greg KH 已经开始学习审查 Rust 补丁）
在内核社区内部培养 Rust 技能（文档、研讨会、结对编程）
从 Rust 社区招募对内核感兴趣的人
使用自动化工具减轻审查负担（clippy lint、bindgen 一致性检查）
设计简单清晰的抽象层，使其容易审查
鼓励”影子审查”（新人在私下审查补丁并与维护者讨论）

2.4 描述避免内核社区中”Rust vs C 宗教战争”的具体策略。

答案

1. **强调补充而非替代**：Rust 是新选项，不是为了取代所有 C 代码 2. **用数据说话**：CVE 统计、性能基准、代码量对比，而非主观意见 3. **尊重 C 维护者的经验**：承认他们对子系统的深度理解 4. **保持同等质量**：Rust 代码必须达到与 C 代码相同的质量标准 5. **避免敌意**：不使用"Rust 比 C 好"等挑衅性说法 6. **共同解决问题**：让 C 维护者参与 Rust 抽象层的设计决策 7. **文化谦逊**：Rust 开发者学习内核方式，而非强行改变内核方式 8. **渐进式**：从无争议的领域开始（如新驱动），避免在敏感子系统强行推进

3. 论述题（40分，每题20分）

3.1 你认为 Rust 在 Linux 内核中 5 年后会发展到什么程度？从技术、社区、产业三个角度进行预测，并论证你的预测基础。

答案

**技术角度**：

5 年后（2030）：

Rust 将在至少 5 个主要子系统中使用：Binder（已合并）、DRM/GPU、网络、块设备、文件系统
至少 2 个生产级 Rust 文件系统驱动
nightly 依赖性减少到 < 3 个特性
GCC Rust 可用，但 LLVM rustc 仍将是主要编译器
性能基准持续显示 Rust 版本与 C 版本持平或更优
Rust 驱动的安全记录显著优于 C 驱动

社区角度：

内核 Rust 审查者数量从 5-8 人增长到 20-30 人
至少 3 名维护者来自 C 背景，通过学习成为 Rust 审查者
内核邮件列表上 Rust 补丁的比例稳步增长（从 <5% 到 15-20%）
新驱动开发者多数选择 Rust

产业角度：

Google（Android）、Samsung、Intel、AMD 投入 Rust 内核开发
至少 5 家芯片厂商提供带有 Rust 驱动支持的 Linux BSP
内存安全合规成为政府和行业要求
保险业认可 Rust 内核驱动具有更低的网络安全风险

论证基础：

历史趋势：一旦证明可行且有益，内核社区倾向于接纳新技术（如 Git、Device Tree、eBPF）
经济压力：安全漏洞的成本持续上升
人力因素：新一代系统程序员更倾向 Rust
行业承诺：Google 和 Microsoft 的公开承诺

3.2 从更宏观的视角，讨论”内存安全语言在系统编程中的兴起”这一趋势。它是否不可逆？Linux 内核在这个趋势中扮演什么角色？

答案

**趋势分析**：

内存安全语言在系统编程中的兴起是由多重因素推动的，这些因素使其成为不可逆的趋势：

安全漏洞成本：约 70% 的严重安全漏洞是内存安全问题。每个漏洞的修复成本（发现、分析、修补、部署、沟通）估计在 $50 k -$ 100k。对于 Linux 生态系统，这意味着每年数十亿美元的损失。
监管压力：美国 CISA 的 “Secure by Design” 倡议、欧盟 Cyber Resilience Act 都在推动软件在设计中就是安全的——而不是通过补丁”加安全”。这意味着未来可能产生法规要求新系统软件使用内存安全语言。
行业承诺：Google（Android、ChromeOS）、Microsoft（Windows）、Amazon（AWS）都已公开承诺在系统软件中优先使用内存安全语言。
人员市场：新一代开发者更倾向 Rust。Stack Overflow 调查连续多年将 Rust 评为”最受喜爱的语言”。
技术成熟：Rust 已经足够成熟用于内核级开发（零成本抽象、无可选 GC、精细化控制）。

不可逆性论证：

趋势不可逆因为：

没有人会开发”新的内存不安全语言”来与 Rust 竞争
安全需求只会增加不会减少
年轻开发者正在用 Rust 而非 C 学习系统编程
成功的案例（Binder 驱动等）会带来更多采用

Linux 内核的角色：

Linux 内核在这个趋势中扮演关键角色：

示范效应：如果 Linux 内核成功采纳 Rust，其他 OS 项目将跟随
验证 Rust 能力：内核是 Rust 作为系统语言能力的”最终考验”
标准制定：内核的 Rust 实践将影响 Rust 语言本身的发展方向
生态建立：内核 Rust 抽象层的模式将成为其他系统软件中 Rust 使用的模板

Linux 内核是系统编程世界的”北极星”——它的技术选择影响整个行业。

本章小结

本章展望了 Rust 在 Linux 内核中的未来。我们讨论了即将被 Rust 化的子系统（网络、文件系统、GPU）、面临的技术挑战（alloc in kernel、LKMM、架构支持、nightly 特性依赖）、社区挑战（C 开发者学习曲线、审查容量）。

核心信息：

Rust 在内核中的采用是不可逆的趋势
技术挑战是可解决的，但需要时间和协作
最大的”瓶颈”是人的能力：需要更多同时理解 Rust 和内核的人
你现在进入这个领域正处在历史最佳时机
每个新的 Rust 内核贡献者都在加速这一历史性转变

最终号召：

成为你希望看到的历史的一部分。

Linux 内核已经运行了 30+ 年。下一个 30 年将由能够证明内存安全可以在操作系统内核中实现的开发者来塑造。

这个人可以是你。

05-参与内核Rust开发 | 01-Linux内核Rust支持概述 | 10-嵌入式与no_std企业应用

RootStack

探索

06-内核Rust未来展望

内核 Rust 未来展望

1. 我们现在的位置（2025）

2. 即将到来的：更多子系统采用 Rust

2.1 网络子系统

2.2 文件系统

2.3 GPU 驱动（DRM 子系统）

2.4 其他潜在子系统

3. 技术挑战

3.1 alloc 在内核上下文中

3.2 内核内存模型（LKMM）

3.3 架构支持

3.4 nightly 特性依赖

3.5 正常化（stabilization）路线图

4. 社区挑战

4.1 C 内核开发者学习 Rust

4.2 维护两套 API

4.3 代码审查容量

4.4 避免”Rust vs C”的宗教战争

5. 宏伟愿景：第一个安全的 OS 内核

5.1 这意味着什么？

5.2 与 seL4 的对比

5.3 时间线预测（推测性）

6. 如何成为这个历史转变的一部分

6.1 现在应该培养的具体技能

6.2 你现在就可以做的事情（今天）

6.3 学习资源清单

6.4 寻找导师

7. 更广阔的视角：Rust 在系统编程中的兴起

7.1 内核之外的 Rust 系统编程

7.2 Rust 在基础设施软件中的采用

7.3 为什么这个趋势不可逆

8. 结束语

8.1 不仅是学习一门语言

8.2 这是一次历史性的机遇

8.3 你的第一步

05-参与内核Rust开发 | 01-Linux内核Rust支持概述 | 10-嵌入式与no_std企业应用

章节考查（100分）

本章小结

关系图谱

目录