【操作系统百科】Rust for Linux

开篇：内核为什么引入 Rust

Linux 内核约 70% 的安全 CVE 与内存破坏相关——该比例来自 Kernel Self Protection Project 等维护者多年统计与 CNA 分类讨论（具体百分比随年份波动，宜查当年 kernel.org 安全公告汇总，本文引用「内存安全类占主导」这一稳定趋势，不编造精确到小数点的 2026 年报）。

Rust 的 所有权 + 借用检查 在编译期消除：use-after-free、double-free、空指针解引用、数据竞争（在 safe Rust 内）。把 Rust 引入 30 年 C 代码库 的代价是：工具链、ABI、抽象层维护、社区技能分裂。

本文对照 KASLR 与缓解：Rust 减漏洞类；KASLR/CFI/Shadow Stack 减利用成功率——正交。

flowchart LR
    C[历史 C 子系统] --> FFI[FFI 边界]
    FFI --> RUST[Rust 驱动 / 模块]
    RUST --> KC[kernel crate 抽象]
    KC --> BIND[bindgen 生成 C API]
    BIND --> C

一、合入主线时间线与能力边界

版本纪律：下文源码路径以 Linux 6.6+ Documentation/rust/ 为锚；读者若用 6.1 需对照 release notes 缺失组件。

二、rust/ 子系统架构

2.1 目录地图

2.2 kernel crate 与模块入口

use kernel::prelude::*;

module! {
    type: MyDriver,
    name: "my_driver",
    authors: ["..."],
    description: "Example",
    license: "GPL",
}

struct MyDriver;

impl kernel::Module for MyDriver {
    fn init(_module: &'static ThisModule) -> Result<Self> {
        pr_info!("Rust driver loaded\n");
        Ok(MyDriver)
    }
}

对照 C module_init：Rust 用 Result 传播初始化错误，避免 C 式「返回负 errno」与资源泄漏交织。

2.3 pin_init 与自引用结构

内核大量结构 自引用（链表节点、含指针的 struct）。Rust 稳定前用 pin_init / PinnedDrop 模式在 构造期 固定地址，避免 move 后指针失效。

原则（A 级：Documentation/rust/general-information.html）：

• 需要稳定地址的字段用 Pin 包装。
• 初始化失败路径由 pin_init 宏生成 drop 链。

2.4 sync::Lock 与 C 锁原语映射

Rust 锁在 编译期 标记 Send/Sync；错误持锁（跨 IRQ 睡眠）尽量在抽象层拒绝。

2.5 错误处理：Result 与 Error

pub fn probe(dev: &Device) -> Result<Pin<KBox<Self>>> {
    let reg = dev.iomap_region(0, None)?;
    // ...
    Ok(Pin::from(kbox!(Self { reg }))
}

? 运算符映射到内核 errno；与 C PTR_ERR 模式对照，减少遗漏检查。

三、与 C 的互操作规则

3.1 #[no_mangle] extern "C" 导出

Rust 回调 C 所需：

#[no_mangle]
pub extern "C" fn rust_helper_do_work(ptr: *mut c_void) -> c_int {
    // safety: 调用约定与 C 侧文档一致
    0
}

3.2 Opaque 类型

C 结构体对 Rust 常为 opaque：仅传递指针，不解引用布局——避免 Rust 与 C 头文件布局漂移。

3.3 bindgen 与 build.rs

内核构建集成 bindgen 从 C 头生成 Rust 绑定；C API 变更 必须同步更新绑定与 kernel crate 安全封装——这是 维护负担 核心。

3.4 FFI 边界安全契约

官方要求：unsafe 集中在薄封装层；驱动业务逻辑尽量 safe。违反时 clippy 与 review 聚焦 unsafe 块。

四、案例路径：从示例到 Asahi GPU

4.1 官方示例模块

6.1 起 samples/rust/ 提供最小字符设备、Rust 版 printk 等——适合验证工具链：

make LLVM=1 rustavailable
make M=samples/rust examples

4.2 块层与网络 Rust 实验

邮件列表与 -next 树常见：Rust 块驱动、phy 驱动实验——合入节奏因子系统维护者态度而异。

4.3 Asahi Linux GPU 驱动（里程碑意义）

Apple Silicon GPU 驱动大量使用 Rust 管理：

• 复杂 命令流与 GPU 状态机
• 内存对象 与 IOMMU 交互
• 用户态接口（ioctl 路径）仍经 C 胶水

意义：非玩具——代码规模与状态空间接近生产 DRM 驱动，证明 Rust 可承载真实硬件复杂性。

五、内存安全：C vs Rust 对照表

边界：unsafe 块内仍可出现上述 bug；FFI 调用 C 仍继承 C 风险。

六、与编译期缓解（CFI、KASAN）的关系

对照 完整性 与 seccomp：Rust 不替代 LSM/沙箱。

七、工具链、ABI 与编译时间

7.1 rustc 版本锁定

内核指定 精确 rustc 版本（见 scripts/min-tool-version.sh 或 Documentation/rust/quick-start.rst）。发行版打包 Rust 内核模块必须用 相同版本 编译——Rust 无稳定 ABI。

7.2 架构支持

并非所有 ARCH= 均 CONFIG_RUST=y；嵌入式架构可能长期缺席。部署前查目标架构 Kconfig。

7.3 编译时间

全内核 LLVM=1 + Rust 增量显著增加链接时间——CI 与开发者笔记本是实际摩擦点。

7.4 调试

gdb 对 Rust 符号支持逐年改善，但仍不如 C 成熟；printk + tracing 仍是主力。

八、局限与未解决问题

8.1 为何不全量重写

• 驱动与 mm/、sched/ 耦合极深。
• 历史行为兼容性（quirk）在 C 中散落注释。
• 审查带宽：Rust PR 需 C 子系统维护者 + Rust 专家双审。

九、eBPF 中的 Rust（Aya）— 相关但不同层

// Aya：用户态加载 + 内核 eBPF 程序可用 Rust 编写
#[kprobe]
pub fn try_kprobe(ctx: ProbeContext) -> u32 {
    match try_kprobe(ctx) {
        Ok(ret) => ret,
        Err(_) => 0,
    }
}

Aya 在 BPF 程序 用 Rust——经过 verifier，与 rust-for-linux 内核模块 不同路径。对照 eBPF 核心。

十、其他语言实验（对照）

十一、对应用开发者的影响

短期（2026）：几乎无——你仍跑同样 syscall、同样 /proc。收益在 长期 内核攻击面下降。

中期：若使用 out-of-tree 驱动 或 自定义模块，可评估 Rust 分支减少内存类 bug。

跟踪源：LWN.net、rust-for-linux 邮件列表、Documentation/rust/。

十二、源码阅读路径（建议顺序）

1. Documentation/rust/quick-start.rst
2. samples/rust/minimal.rs
3. rust/kernel/lib.rs — 模块与错误
4. rust/kernel/sync/ — 锁抽象
5. Asahi 或 DRM Rust 驱动（按当前主线文件名）

十三、小结

• Rust for Linux 目标：在 保留 C 子系统 前提下，用 所有权 削减内存安全类 CVE。
• Linux 6.1 起 rust/ + kernel crate；pin_init、sync::Lock、Result 是日常 API 核心。
• FFI + bindgen 是维护成本中心；unsafe 集中封装 是官方安全策略。
• Asahi GPU 等驱动证明规模可行性；全量重写 不现实。

• 与 KASLR/CFI/eBPF 正交互补；应用开发者 现在 主要「关注主线」，out-of-tree 作者可 试点 Rust。

附录 1、工程深化：pin_init! 宏展开语义

flowchart LR
  Q[pin_init! 宏展开语义] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 pin_init! 宏展开语义 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 2、工程深化：PinnedDrop 与驱动 teardown

flowchart LR
  Q[PinnedDrop 与驱动 teardown] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 PinnedDrop 与驱动 teardown 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 3、工程深化：kernel::sync::Mutex 睡眠路径

flowchart LR
  Q[kernel::sync::Mutex 睡眠路径] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 kernel::sync::Mutex 睡眠路径 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 4、工程深化：SpinLock 与 preempt 边界

flowchart LR
  Q[SpinLock 与 preempt 边界] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 SpinLock 与 preempt 边界 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 5、工程深化：Result 到 errno 映射表

flowchart LR
  Q[Result 到 errno 映射表] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Result 到 errno 映射表 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 6、工程深化：ThisModule 生命周期

flowchart LR
  Q[ThisModule 生命周期] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 ThisModule 生命周期 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 7、工程深化：bindgen 布局测试

flowchart LR
  Q[bindgen 布局测试] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 bindgen 布局测试 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 8、工程深化：opaque type 封装模式

flowchart LR
  Q[opaque type 封装模式] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 opaque type 封装模式 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 9、工程深化：#[vtable] trait 对象

flowchart LR
  Q[#[vtable]  trait 对象] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 #[vtable] trait 对象 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 10、工程深化：module_parameters 与 sysfs

flowchart LR
  Q[module_parameters 与 sysfs] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 module_parameters 与 sysfs 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 11、工程深化：Device::probe 返回值

flowchart LR
  Q[Device::probe 返回值] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Device::probe 返回值 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 12、工程深化：PlatformDriver 匹配表

flowchart LR
  Q[PlatformDriver 匹配表] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 PlatformDriver 匹配表 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 13、工程深化：DMA buf Rust 封装

flowchart LR
  Q[DMA buf Rust 封装] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 DMA buf Rust 封装 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 14、工程深化：ioctl 命令安全包装

flowchart LR
  Q[ioctl 命令安全包装] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 ioctl 命令安全包装 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 15、工程深化：wait_queue 条件变量

flowchart LR
  Q[wait_queue 条件变量] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 wait_queue 条件变量 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 16、工程深化：Arc 禁用说明

flowchart LR
  Q[Arc<RefCell> 禁用说明] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Arc 禁用说明 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 17、工程深化：no_std alloc 错误处理

flowchart LR
  Q[no_std alloc 错误处理] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 no_std alloc 错误处理 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 18、工程深化：panic=abort 内核策略

flowchart LR
  Q[panic=abort 内核策略] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 panic=abort 内核策略 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 19、工程深化：rustc 版本与 RUSTC_LLVM_VERSION

flowchart LR
  Q[rustc 版本与 RUSTC_LLVM_VERSION] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 rustc 版本与 RUSTC_LLVM_VERSION 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 20、工程深化：Clippy 内核 allow 列表

flowchart LR
  Q[Clippy 内核 allow 列表] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Clippy 内核 allow 列表 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 21、工程深化：rustfmt 内核风格

flowchart LR
  Q[rustfmt 内核风格] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 rustfmt 内核风格 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 22、工程深化：6.1 samples/rust _walkthrough

flowchart LR
  Q[6.1 samples/rust _walkthrough] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 6.1 samples/rust _walkthrough 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 23、工程深化：6.6 Documentation/rust 索引

flowchart LR
  Q[6.6 Documentation/rust 索引] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 6.6 Documentation/rust 索引 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 24、工程深化：DRM Rust 子模块

flowchart LR
  Q[DRM Rust 子模块] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 DRM Rust 子模块 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 25、工程深化：block multiqueue 实验

flowchart LR
  Q[block multiqueue 实验] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 block multiqueue 实验 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 26、工程深化：phy Rust 驱动邮件列表

flowchart LR
  Q[phy Rust 驱动邮件列表] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 phy Rust 驱动邮件列表 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 27、工程深化：rustversion 条件编译

flowchart LR
  Q[rustversion 条件编译] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 rustversion 条件编译 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 28、工程深化：cfg CONFIG_RUST 门控

flowchart LR
  Q[cfg CONFIG_RUST 门控] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 cfg CONFIG_RUST 门控 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 29、工程深化：Kconfig 依赖 RUSTC

flowchart LR
  Q[Kconfig 依赖 RUSTC] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Kconfig 依赖 RUSTC 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 30、工程深化：发行版 kernel-rust 包

flowchart LR
  Q[发行版 kernel-rust 包] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 发行版 kernel-rust 包 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 31、工程深化：out-of-tree Rust ko 构建

flowchart LR
  Q[out-of-tree Rust ko 构建] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 out-of-tree Rust ko 构建 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 32、工程深化：modpost Rust 符号导出

flowchart LR
  Q[modpost Rust 符号导出] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 modpost Rust 符号导出 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 33、工程深化：GDB pretty printer Rust

flowchart LR
  Q[GDB pretty printer Rust] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 GDB pretty printer Rust 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 34、工程深化：tracing 在 Rust 驱动

flowchart LR
  Q[tracing 在 Rust 驱动] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 tracing 在 Rust 驱动 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 35、工程深化：warn 与 pr_warn 映射

flowchart LR
  Q[warn 与 pr_warn 映射] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 warn 与 pr_warn 映射 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 36、工程深化：FFI 审查 checklist

flowchart LR
  Q[FFI 审查 checklist] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 FFI 审查 checklist 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 37、工程深化：unsafe 集中目录策略

flowchart LR
  Q[unsafe 集中目录策略] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 unsafe 集中目录策略 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 38、工程深化：KCSAN 与 Rust 交错

flowchart LR
  Q[KCSAN 与 Rust 交错] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 KCSAN 与 Rust 交错 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 39、工程深化：KFENCE 抽样检测

flowchart LR
  Q[KFENCE 抽样检测] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 KFENCE 抽样检测 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 40、工程深化：CFI 与 Rust vtable

flowchart LR
  Q[CFI 与 Rust vtable] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 CFI 与 Rust vtable 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 41、工程深化：KASLR 无关性重申

flowchart LR
  Q[KASLR 无关性重申] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 KASLR 无关性重申 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 42、工程深化：CVE 分类统计方法

flowchart LR
  Q[CVE 分类统计方法] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 CVE 分类统计方法 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 43、工程深化：Asahi GPU 状态机片段

flowchart LR
  Q[Asahi GPU 状态机片段] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Asahi GPU 状态机片段 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 44、工程深化：Apple Silicon IOMMU

flowchart LR
  Q[Apple Silicon IOMMU] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Apple Silicon IOMMU 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 45、工程深化：Linus rust 邮件态度引用

flowchart LR
  Q[Linus rust 邮件态度引用] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Linus rust 邮件态度引用 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 46、工程深化：C 维护者不强制学 Rust

flowchart LR
  Q[C 维护者不强制学 Rust] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 C 维护者不强制学 Rust 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 47、工程深化：Hubris 嵌入式对照

flowchart LR
  Q[Hubris 嵌入式对照] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Hubris 嵌入式对照 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 48、工程深化：Aya eBPF 用户态 Rust

flowchart LR
  Q[Aya eBPF 用户态 Rust] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 Aya eBPF 用户态 Rust 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 49、工程深化：async 内核未来邮件

flowchart LR
  Q[async 内核未来邮件] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 async 内核未来邮件 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 50、工程深化：编译时间 benchmark 方法

flowchart LR
  Q[编译时间 benchmark 方法] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 编译时间 benchmark 方法 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 51、工程深化：LTO thin 与 Rust

flowchart LR
  Q[LTO thin 与 Rust] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 LTO thin 与 Rust 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 52、工程深化：CI kernel-selftests rust

flowchart LR
  Q[CI kernel-selftests rust] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 CI kernel-selftests rust 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 53、工程深化：rust-analyzer 内核限制

flowchart LR
  Q[rust-analyzer 内核限制] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 rust-analyzer 内核限制 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

附录 54、工程深化：docs 翻译贡献路径

flowchart LR
  Q[docs 翻译贡献路径] --> E[证据台账]
  E --> I[工程决策]
  I --> R[回滚策略]

读者若维护生产系统，应把 docs 翻译贡献路径 纳入架构评审清单——与 容器隔离、虚拟化 等篇形成闭环，而非孤立采纳单一技术。

参考文献

• rust/ 目录（Linux 内核）
• Documentation/rust/
• Miguel Ojeda, “Rust for the Linux kernel.” 2022
• Asahi Linux GPU driver

工具

• rustc（nightly）
• bindgen
• make LLVM=1 rustavailable

上一篇：Unikernel 下一篇：机密计算