【Rust日报】2026-09-24 Linux 将移除 Binder C 驱动，全面改用 Rust
内容提要
Linux 内核将移除维护超15年的 Binder C 驱动，全面改用已在 Android 运行的 Rust 实现，补丁删除约1.1万行 C 代码，计划随 Linux 7.4 合入。Rust 的 allocator_api 子集稳定，预计随 1.100 发布，支持自定义分配器。hashify 0.3 实现编译期完美哈希，比 phf 快约4–12倍。r/rust 不再欢迎纯代码仓库分享。
延伸解读
Binder 驱动更替的工程意义
Binder C 驱动维护超15年，复杂度持续上升，新增功能易引入漏洞。Rust 实现已在 Linux 6.18 上游并在 Android 设备运行，达到功能对等，性能可匹配甚至超过 C 版本。移除约1.1万行 C 代码，计划随 Linux 7.4 合入。这标志着 Rust 在内核关键组件中从实验走向生产，为其他驱动迁移提供参考。
allocator_api 稳定的影响与限制
allocator_api 子集稳定，目标 Rust 1.100。MVP 包括 Allocator trait、带分配器的 Box/Vec 及 Global/System 实现。但标准库其他集合的分配器支持留待后续，Box::into_pin 对自定义分配器暂不可用。实现者需注意不得在 trait 方法或 drop 中 unwind。这为自定义分配器提供基础，但生态全面适配仍需时间。
hashify 0.3 的性能提升与适用场景
hashify 0.3 重写查找引擎，根据键数自动选择策略：≤16 键用决策树，17-64 键用种子搜索，>64 键用最小完美哈希。在 Apple M5 Max 上对比 phf 0.14，map! 快约 4.1-12.6 倍。生成代码无运行时依赖、不分配、无 unsafe，适合固定键集合如 IMAP 命令、HTTP 方法等关键字识别。
r/rust 新规对分享者的启示
r/rust 不再欢迎纯代码仓库分享，视为 Low-Effort。非新闻性新库公告需满足：持续开发约4个月、已有实际使用、完整正文、说明相关性、写清权衡差异、不得 AI 生成。这鼓励更深入的讨论，分享者应准备技术文章而非仅链接仓库，或参与每周工作帖。
Q&A
Linux 为什么要移除 Binder C 驱动？
因为 C 驱动维护超过 15 年，复杂度持续上升，新增功能容易引入漏洞；而 Rust 实现缓解了多数问题，且性能可匹配甚至超过 C 版本，因此不再视为实验。
Rust Binder 驱动目前的状态如何？
Rust Binder 已在 Linux 6.18 上游，并在 Android 设备上运行一段时间，已达到功能对等。
allocator_api 稳定后，Rust 1.100 会带来哪些新能力？
稳定了 Allocator unsafe trait（含 allocate/deallocate 及默认方法）、带分配器参数的 Box<T, A> 和 Vec<T, A> 及其构造拆解 API、Global 与 System 实现，以及对 &A、&mut A、Box/Rc/Arc 包装分配器的实现。
hashify 0.3 相比 phf 的性能提升有多大？
在 Apple M5 Max、Rust 1.98 上用 criterion 对比 phf 0.14，map! 相对默认 phf 约快 4.1x–12.6x，相对 phf+ptrhash 约快 3.2x–8.8x。
r/rust 对纯代码仓库分享的新规定是什么？
仅贴代码仓库链接的 Code Dump 不再欢迎，视为 Low-Effort，除非本身具新闻性。非新闻性的新库公告需满足持续开发约 4 个月、已有实际使用或二次开发、有完整正文或文章、说明相关性、写清与同类库的权衡差异，且不得为 AI 生成。
hashify 0.3 的查找引擎是如何根据键数量选择策略的？
键数 ≤16 时生成类似 gperf --switch 的决策树；17–64 键搜索 seed，落入二的幂次表；超过 64 键则构建最小完美哈希，借鉴 PtrHash 与 PHast，键分桶、每桶一字节 pilot，经两次 multiply-high 得到槽位，pilot 搜索用类似 cuckoo 的驱逐。
