如何看 Hector Martin 退出上游 Linux 内核开发这件事？

补一下 Hacker News 的讨论地址： https://news.ycombinator.com/item?id=42972062
我认为有一层说的非常好「这是 Linus 的失败，他在 Rust 上模棱两可」。
没有说可以，也没有说绝对不行，而是只允许 Rust 开发驱动这种“不是非常核心的部分”。所以矛盾就转为 Rust 开发者想要更上游，而 Old money 觉得他们不够格。
这甚至可以说是一种鄙视链了，而矛盾的核心就是 Linus 。

没什么问题 ，整个内核都是用 c 开发的， 突然整出一个 rust 要合进主线， 弄的 rust 和 c 混合，编译器都不一样，rust 编译一下，c 编译一下 ，虽然有自动化编译脚本辅助，但还是很不适。谴责不了别人

这个没得喷，Linux 内核确实不建议混合开发，不好编译和调试，出问题也不好诊断

@songray
@liaohongxing
@beginor

我觉得 linus 既然决定了让 rust 进入 linux ，那么 linus 应该说服主要的 linux 开发者接受并且一起支持这件事，因为 rust 进入 linux 会不可避免的影响到原来只用 c 语言的开发者，如果这件事一开始就没有在主要的 linux 开发者中达成共识，我甚至认为就不应该把 rust 添加到 linux 中。

我个人是不喜欢在 Linux 内核中使用 rust 语言的，但是我对 marcan 在 asahi linux 项目中所作出的工作感到非常敬佩，asahi linux 项目应该是第一个实际用 rust 语言编写 linux 驱动并给用户用的项目，刚刚看了一下 asahi linux 内核中用 rust 编写的 GPU 驱动程序 drm/asahi 都已经有 2 万行代码了。

RIIR 收收味。其实大概就是 driver 太多质量不好控，写（维护） driver 的人水平参差不齐，用 rust 让它们安全一点。

上表情包 "用 rust 重构"

早有苗头： ?t=1560

解决也简单，需要有一条明确的线，这条线之下 Rust 能做，这条线之上 Rust 别碰。

比如驱动 Rust 能做这个大家已经快有共识了，那视频里的 fs Rust 能不能碰？

必须有一个终身仁慈独裁者来画一条线，以及在未来合适的时机变动这条线

支持 Linus 大叔就对了。Rust 掺合进内核这种事情，不可操之过急。最好干脆禁止。

Linux 内核开发必须保证语言一致性, Linux 能几十年长久不衰, 靠的不就是 Linus 的坚持么. 我担心 Linus 去世了之后, Linux 宇宙还能不能找到这样的领袖.

我实在不明白为什么这么执着于进入主线。。

自己开个分支想怎么写怎么写，，想重写哪部分就重写哪部分，，完全没人干预。。

如果你实现的功能运行更快、更安全、还更省资源，，那大家甚至可以承认你才是主线，，让 linux 本人的主线靠边站。。

所以你们为啥非要挤进人家那群写 C 的老头子队伍里面去？？你们就不能自己搞个分支自己写吗？？是对 rust 没信心，还是对自己的能力没信心？？

@XIVN1987 #10 不进主线，怎么能证明自己呢？

@XIVN1987 不进主线，意味着要像创业公司一样去宣传和经营自己的产品了，很难的。

@XIVN1987 前段时间的 xz 事件忘了？

@zzz22333
什么意思？？没看明白。。

开发出好的功能、好的软件，，获得用户的认可，，就能证明自己啊。。

@dalaoshu25

xz 是谁？？是个程序员吗？？

@XIVN1987 #14 换个角度吧，如果你做了一个 feature ，能合并入 Linux 主线，与 你合入自己的分支。两者带给你的声誉完全不一样。

@GeekGao
#12 只有主线才有用户群体，才能更好的“证明”自己，你在分支上玩，受众太少，就难以获得名声。
#14 xz 是有一次供应链投毒的主角，有 linux 开发这卧底很久，在代码里投毒，影响了很多 linux 发行版。

@wniming #4

是的，虽然我也很不喜欢 linux 内核中带上 rust ，但是很敬佩 marcan 所做出的工作。

linux 内核带上 rust 我个人是比较反感的, 因为在 linux kernel 这边的话, rust 的工具链和兼容性不可能达到 c 的水平(主要是 linux kernel 的特殊场景导致的)。

rust 写比较底层的确实没问题，但是像 linux kernel 这种历史比较久而且要求尽可能轻便并有较强兼容性的场景，rust 非常不适合，并且所谓的由编译器保证的安全性从某种程度上来说也会成为边缘情况下的阻碍。

@XIVN1987 #15 潜伏 3 年，xz 投毒事件

我怎么感觉有点拆迁队的感觉？人家房子盖得好好的，一堆人抡着 rust 过来就要强拆重建？

@tomychen 鸠占鹊巢、抢班夺权

不意外吧，从 linus 的 show me your nationality 开始，Linux 内核社区已经有明面上不可弥补的裂痕了。有生之年估计真能看到 linux 社区分裂

虽然我也很喜欢 rust ，但是我不喜欢 kernel 代码中混杂着 rust

我也不希望看到 rust 进入主线内核，但这锅应该 Linus 来背，他的态度模糊导致了其他人的工作白费，虽然 Martin 试图借助媒体闹大给内核维护团队施压也不好；还有就是内核确实该考虑引入一些现代语言了，最起码该划一个 Cpp 的子集，一直坚持 C 那只能让内核维护团队的平均年龄越来越大

大部分人阅读能力等于零

rust 程序员只适合重写，整天问有什么可以重写的项目，让他们添砖加瓦是做不到的

@tomychen #18 实际上是房子频繁出问题，拆迁队早就赶过来说我给你免费拆，后续建我也包了（会抽人维护接口兼容性），房子主人（ Linus ）既不说好、也不说不好，搞得人家拆迁队走也不是、不走也不是，在旁边心存希望住了两三年，还要天天被某些房客扔狗屎恶心（某内核开发者故意天天改 interface 来恶心 RIL Team ）。

最后拆迁队实在绷不住了，敲门问能不能先改下你家庭院，结果直接被认定为强拆强建，拆迁队愤而跑路。

@nicaiwss #23 都 2025 年了还有人信这种言论？也就骗骗自己了。

这样吧，你访问 https://github.com/trending/rust?since=monthly ，然后看看是不是重写，好吗？

Rust 开发人员和（不愿意写 Rust 的）Ｃ 开发人员的矛盾是不可调和的。

内核内部没有稳定 API ，这赋予了维护者想改什么东西就改什么东西的权力，可以随时改进、重构。如果改 X 模块的时候 Y 模块炸了，那 X 的维护者只需要顺带着把 Y 模块弄好就行。这事儿是很常见的。而加入 Rust 之后那可就不一样了：维护者改了 X 的 C 代码，Y 模块那边的 Rust 代码炸了，这谁负责？

按照原有规矩，C 的人就不得不去弄那个 Rust 代码，基本等于强迫 C 的人写 Rust 了，C 的人当然不愿意。所以 Rust 的人就承诺，如果改 C 代码把 Rust 改炸了的话，Rust 代码由 Rust 的人负责修。

这个承诺是很扯淡的。原本没有 Rust 的情况下，改炸了顺手修就完了，反正都是 C 语言。现在 C 的人要重构一下，还得要给 Rust 的人发邮件、等 Rust 的人来修。这要是 Rust 的人回复晚了赶不上合并窗口怎么办，这要是一两个星期都不回复（比如在度假）怎么办，要是跳出来扯皮那怎么办。而且说，有些 C 写的模块，都存在十几甚至几十年了，C 的人也维护了十几甚至几十年了，允许他们随时改进、重构代码，这确实是应该的，原有的规矩也确实如此。现在好了，重构得看 Rust 的人的脸色了。舆论上出事的模块都是这些，什么 FS 什么 DMA ，老模块了，被各个其他模块调用，一改就炸一片，未来哪天炸在 Rust 模块的头上那是必然的。

既然不可调和，那这事儿也简单，Rust 的人和（不愿意写 Rust 的） C 的人两边之间选一边开除就是了。别说什么得罪人，Linus 和 Greg K-H 连 Chinese 和 Russians 都能开除，那没有什么是不能开除的。

@w568w 好吧。说实话，如果 rust 真参与内核，每天面对那么高比例的 unsafe 代码，心里真的不会膈应吗？真的有心情开发新功能吗？难道不是先想办法把 unsafe 的范围缩小吗？

@nicaiwss #27 RIL 其实并没有「那么高比例」的 unsafe 代码。除了和 C 对接的接口，其他几乎是完全 safe 的。

=============

另外我发觉很多人阅读能力确实为 0 。就引发争论的这件事而言，Rust in Linux 提交的补丁不是想「重写」内核中的东西，或者把看不顺眼的东西换成 Rust ，他们只是想「使用」 DMA 子系统。

他们提交的补丁主要涉及 DMA 的接口描述。再强调一遍，「并没有往 DMA 的 C 部分中加入任何 Rust 代码，是 Rust 编写的其他子系统需要用 DMA 」。有多少人看到标题就开始闭眼刷 RIIR （ Rust 重写一切）？

但仅这一点，就让负责 DMA 子系统的 C 维护者强烈反对了。这就意味着（一旦驱动依赖该子系统）主线中无法出现可用的 Rust 驱动，所以才让 Martin 沮丧。

学习 neovim ，再开一条线。 挺好

非常好 迷你、编译快速以及省资源很重要
rust 的安全限制本质上是另类的框架
曾几何时 linux 越来越像 windows 了

亟需来个人跨时代, 用 Rust 重新 Linux.

我发现上面的的回复和这次的事件没什么关系啊，什么 rust 进入主线内核，什么重写，这都什么玩意啊，到底有没有详细看啊。

@w568w 应该也算是加入了，rust 这边希望在 kernel/dma 中添加 rust 代码来抽象 c 的 dma api ，dma 维护的不希望在 dma 目录中出现 rust 代码，我觉得倒是可以说的通。

@XIVN1987 其实是可以的
要是能做到 api 兼容，其实真的可以抢 linux kernel 的生意

@nlzy 你这样一说确实是不可调和的矛盾了，还是让 rust 自己开分支维护吧，让用户决定 C kernel 和 RUST 哪个更好

只是个插曲而已~ marcan es espaol, de puta madre, solo un poco.

@SenLief 所有的代码都在 rust 目录下，只是用了 dma 的 api 。
https://lore.kernel.org/lkml/[email protected]/

@XIVN1987 有一条小路, 走的人多了, 就成了大路, 看看那么多 linux 的分支...

@nlzy 但是更恶劣的是那个 maintainer 说 "And I also do not want another maintainer." 这个 another 是否包含 C 开发者呢。https://lore.kernel.org/rust-for-linux/[email protected]/

意思是这个模块只有他能改吗。感觉这个已经不是 r4l 的问题，而是 linux 这个项目有问题了，linus 是“仁慈的独裁者”，然后下面的 maintainer 个个也有样学样要当独裁者吗？