Linux 将移除 Binder C 驱动，全面改用 Rust
Binder 是 Android 使用的 Linux 内核 IPC 机制，其 C 实现长期位于主线内核。过去几年 Google 用 Rust 重写了 Binder，并作为早期“真实” Rust 驱动之一合入；Rust Binder 已在 Linux 6.18 上游，并在 Android 设备上运行一段时间。面向即将到来的 Linux 7.4 周期，旧的 Binder C 驱动准备退役。
Google 工程师 Carlos Llamas 在删除约 1.1 万行旧 C 代码的补丁说明中写道：C 驱动维护超过 15 年，复杂度持续上升，新增功能容易踩到漏洞；Rust 实现缓解了多数问题。Alice Ryhl 等工作使 Rust Binder 达到功能对等，性能可匹配甚至超过 C 版本，因此不再视为实验。Greg Kroah-Hartman 已将该移除补丁收入 char-misc-next，计划随 Linux 7.4 merge window 提交。
原文链接：https://www.phoronix.com/news/Google-Binder-C-Goodbye
allocator_api 稳定，预计随 Rust 1.100 发布
allocator_api（跟踪 issue #32838，源自 RFC 1398）子集已稳定，合并 PR 为 #156882，目标版本 Rust 1.100。其余部分将改名为 allocator_ext。稳定工作由 t-libs、wg-allocators 以及 t-types / t-lang / t-opsem 等协作完成。
本轮稳定的 MVP 包括：Allocator unsafe trait（allocate / deallocate，以及 allocate_zeroed、grow / grow_zeroed、shrink 等默认方法）；带分配器参数的 Box<T, A>、Vec<T, A> 及 new_in / with_capacity_in / from_raw_parts_in 等构造与拆解 API；Global 与 System 实现；以及对 &A、&mut A、Box/Rc/Arc 包装分配器的实现。by_ref 已移除。对标准库其他集合的分配器支持留待后续。
实现者安全要求收紧：不得在 trait 方法或 drop 中 unwind；与 Clone 相关的部分约束调整；Allocator 定为 dyn-compatible。自定义分配器与 Box/Pin 交互中发现的若干健全性问题推动引入不稳定的 StaticAllocator 等后续机制；Box::into_pin 对自定义分配器暂不可用。Store 提案可向后兼容叠加，细节延后。
原文链接：https://github.com/rust-lang/rust/pull/156882
hashify 0.3：编译期完美哈希，比 phf 快约 4–12 倍
hashify 是过程宏 crate，把固定键集合在编译期生成完美哈希查找；生成代码无运行时依赖、不分配、无 unsafe。Stalwart 用它识别 IMAP 命令、JMAP 属性、头字段名等关键字集合。
0.3 重写了查找引擎并取消手动策略选择：键数 ≤16 时生成类似 gperf --switch 的决策树（先比长度，再比区分字节或两字节 XOR，不计算哈希）；17–64 键搜索 seed，落入二的幂次表，查找为一次乘法、移位与加载；超过 64 键则构建最小完美哈希，借鉴 PtrHash 与 PHast：键分桶、每桶一字节 pilot，经两次 multiply-high 得到槽位，pilot 搜索用类似 cuckoo 的驱逐。0.2 基于 PTHash；紧凑 pilot 与驱逐来自更新工作。
在 Apple M5 Max、Rust 1.98 上用 criterion 对比 phf 0.14：map! 相对默认 phf 约 4.1x–12.6x，相对 phf+ptrhash 约 3.2x–8.8x。例如 HTTP methods（9）hits 约 0.68 ns（相对 phf 约 12.6x），IMAP commands（26）hits 约 0.89 ns（约 10.5x），Sieve keywords（128）与 charset names（149）hits 约 1.8–1.9 ns（约 5x），2125 个 HTML entities hits 约 1.85 ns（约 4.9x）。代码与基准见仓库。
原文链接：https://github.com/stalwartlabs/hashify
r/rust：不再欢迎纯代码仓库 “Code Dump”
r/rust 版主发文更新规则：仅贴代码仓库链接的 Code Dump 不再欢迎。若只想分享自己做的项目，可在每周 “What's everyone working on this week?” 帖下留言。
说明称，早期 Rust 项目稀少时 Code Dump 有示范与庆祝意义；约 15 年后同类 hypervisor / webserver / TUI 重复贴已缺乏讨论价值，且近年大量 AI 生成内容进一步稀释质量。版块目标是讨论语言、生态与社区；多数 Code Dump 几乎不引发与 Rust 相关的讨论。
新规则要点：应用或库的 Code Dump 视为 Low-Effort，除非本身具新闻性（例如首个某领域突破、大公司首次 Rust 应用等）。非新闻性的新库公告需同时满足：至少持续开发约 4 个月；已有实际使用或二次开发；完整正文或文章（README 不算）；说明对 r/rust 的相关性；写清与同类库的权衡差异；且不得为 AI 生成。足够流行的库的 release notes 仍可接受。以 Rust 为中心、项目仅作上下文的技术文章始终欢迎。
原文链接：https://www.reddit.com/r/rust/comments/1wkmzun/no_more_code_dumps/
From Rust中文社区 Mike
社区学习交流平台订阅：
评论区
写评论还没有评论