Linux 内核邮件列表围绕内核中 Rust 编程语言的使用展开的闹剧仍在继续。Linus Torvalds 在很大程度上避免参与正在进行的 LKML 讨论,该讨论围绕 Linux 内核的 Rust 政策以及对 Rust 持有不同观点的内核开发人员和维护人员之间的内斗。在 Linux 第二大维护者 Greg KH 表态支持 Rust 后^1,Linus Torvalds 决定加入讨论。
几天前有评论称 Linus Torvalds 表示他会不顾维护者的反对而合并 Rust 内核代码^2,但在回应 Christoph Hellwig 时,他进一步澄清了自己的立场。Hellwig 身为 DMA 维护者,一直反对将 Rust 代码与内核的 DMA 区域合并。Linus Torvalds 作出回应^3,澄清说,维护者可以选择在他们负责的内核区域中积极参与 Rust 绑定,也可以采取不干预的方式,使其更能补充他们的代码。但内核维护者不能反对新的 Rust 代码作为其 C 代码的有效“用户”。Linux 内核维护者可以参与任何提议的 Rust 代码,也可以选择不参与,让它在内核中互补,但他们不能任意阻止 Rust 代码成为他们代码的用户。
我曾抱有希望,并试图看看这个漫长的讨论是否能产生一些建设性的结果,但现在看来,事情似乎在倒退(或者至少没有进展)。
事实是,你反对的那个拉取请求根本没有触及 DMA 层。
它只是另一个使用 DMA 层的用户,位于完全独立的子目录中,没有以任何方式改变你维护的代码。
我感到不安的是,你竟然在抱怨新用户使用你的代码,然后还不断提出这些完全站不住脚的论点。
老实说,你一直在做的,基本上就是在说“作为 DMA 维护者,我控制 DMA 代码的用途”。
而这根本不是这样运作的。
接下来是什么?说某些驱动程序不能使用 DMA ,因为你不喜欢那个设备,而作为 DMA 维护者,你控制谁可以使用 DMA 代码?
这正是你试图对 Rust 代码做的事情。
说你不同意 Rust——这没问题,没有人要求你编写或阅读 Rust 代码。
但随后你采取了一种立场,认为 Rust 代码甚至不能使用或与你维护的代码交互。
所以让我非常明确地说:如果你作为维护者认为你可以控制谁或什么可以使用你的代码,你错了。
我在技术上尊重你,也喜欢与你合作。
不,我不是在寻找应声虫,我喜欢你指出我的错误。我有时会说一些愚蠢的话,需要有敢于站出来告诉我我错了的人。
但现在,我要指出你的错误。
所以这封邮件不是关于某些“Rust 政策”。这封邮件是关于一个更大的问题:作为维护者,你负责你的代码,没错——但你并不负责谁使用最终结果以及如何使用。
你不必喜欢 Rust 。你也不必关心它。这一点从一开始就很清楚,没有人被迫突然学习一门新语言,那些只想在 C 语言方面工作的人完全可以继续这样做。
所以回到你声明的核心:
“该文档声称没有任何子系统被强制要求采用 Rust”
这一点非常正确。
你没有被强制要求接受任何 Rust 代码,或关心 DMA 代码中的任何 Rust 代码。你可以忽略它。
但“忽略 Rust 方面”自动也意味着你在 Rust 方面没有任何发言权。
你不能两者兼得。你不能说“我不想与 Rust 有任何关系”,然后在下一句话中说“这意味着我将忽略的 Rust 代码不能使用我维护的 C 接口”。
想要参与 Rust 方面的维护者可以参与其中,通过参与,他们将对其 Rust 绑定的外观有一定的发言权。他们基本上也成为 Rust 接口的维护者。
但选择“我不想处理 Rust”的维护者显然也不必费心处理 Rust 绑定——但因此他们在 Rust 方面也没有任何发言权。
所以当你更改 C 接口时,Rust 方面的人将不得不处理后果,并修复 Rust 绑定。这就是这里的承诺:对于那些不想处理 Rust 问题的 C 开发者来说,有一个“保护墙”,承诺他们不必处理 Rust 。
但这“保护墙”基本上是双向的。如果你不想处理 Rust 代码,你在 Rust 代码上就没有发言权。
换句话说:“没有人被迫处理 Rust”并不意味着“每个人都允许否决任何 Rust 代码”。
明白了吗?
不,我实际上并不认为这需要如此黑白分明。我上面用非常黑白分明的术语陈述了这一点(“成为 Rust 绑定的维护者”与“完全不想处理 Rust”),但在许多情况下,我怀疑这条线会不那么严格,子系统维护者可能知道 Rust 绑定,并愿意与 Rust 方面合作,但可能不会非常积极地参与。
所以这真的不必是一个“全有或全无”的情况。
本文使用机器翻译和人工修正。
原文链接:https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers
1
wniming 22 小时 45 分钟前 via Android ![]() 这是一个好消息
|
2
zzz22333 22 小时 45 分钟前
这是说 linus 还是支持 rust 进内核?
|
![]() |
3
AFOX 22 小时 22 分钟前
省流:
如果只想参与 C 代码开发,则失去关于 rust 代码的发言权,因为对于那些不想处理 Rust 问题的 C 开发者来说,有一个“保护墙”,承诺他们不必处理 Rust 。 但是祖师爷认为不必如此黑白分明,大部分情况下维护者还是愿意与 Rust 贡献者合作。 大概是这个意思。 |
![]() |
4
XIVN1987 22 小时 2 分钟前
感觉大神说的很对。。
|
![]() |
5
kk2syc 21 小时 53 分钟前 ![]() @zzz22333 不,linus 的意思应该理解为:
1. 他不支持也不反对 rust 在非核心区域的使用。 2. Hellwig 作为 DMA 维护者,只要管好自己的 c 代码就好了,至于下游(位于完全独立的子目录中)想要用 c 也好还是 rust 也好,他们自己会处理好了绑定关系,不要你费心来拿主意、定规矩。 |
![]() |
9
kk2syc 21 小时 36 分钟前
@bxb100 他的意识是下游爱用啥用啥,你作为 DMA 维护者管好核心就行了,不明白你怎么理解的实质意义的支持?
你试试看 rust 进 core 看看? linus 估计一脚给你踹出去 (不是对你的,只是这个表情很应景) ![]() |
![]() |
11
kk2syc 21 小时 32 分钟前
@zzz22333 看#9 ,linus 说的是下游用户,就是 你我维护好 linux 的核心代码( c ),没必要管下游那群人用什么语言( rust 也好、cpp 也好、c 也好),他们自己会处理好 abi 绑定的事情,这事情我们不用操心,不要拉低自己的档次。
|
![]() |
12
kk2syc 21 小时 29 分钟前
@bxb100 麻烦看看原文吧,讨论的是 user ,不是 maintainer 。
Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for". What's next? Saying that particular drivers can't do DMA, because you don't like that device, and as a DMA maintainer you control who can use the DMA code? |
![]() |
13
Nugine0 OP Linus 的态度是明确反对 c++ 进内核,支持在内核驱动方面引入 Rust ,并且是合并到主线,不是 out of tree 。
|
14
FantaMole 21 小时 25 分钟前 ![]() 既然说到了 linus ,提个题外话。美国政府已经认定俄罗斯并非侵略者了,那 Linux 内核项目是不是又可以允许俄罗斯开发者维护了
|
![]() |
16
Nugine0 OP @zzz22333 这件事是有维护者反对一个 Linux 主线中的 Rust PR ,Linus 表示你这个 C 方面的维护者无权阻止合并……
|
![]() |
17
kk2syc 21 小时 5 分钟前
|
![]() |
18
Nugine0 OP @kk2syc 你看错了,Linus 是回应 Christoph Hellwig 。硬要比喻也是菜刀研发者无权管理菜刀生产线开工还是停工。同一个工厂,不同分工。
|
20
james122333 20 小时 21 分钟前 via Android
我讚同不进内核 即便是放在不同位置
因为无法确保能正常运行 到时被打扰是有可能的 可以用外部项目方式 不少驱动都是外部的 此件事情盲猜应该是有力人士施压 不得不表态从另外角度说人错 我也不想编译个核心还要装个 rust 不然得想方设法改参数 rust 又不 minimal |
![]() |
21
Nugine0 OP @james122333
有力人士施压这个无法证明也无法证伪,上次他们开除俄罗斯开发者就没承认到底为什么,不能排除美国信创影响。 确实有内核开发者提到裁剪 Rust 的问题,目前的共识看起来是要做到完全剔除 Rust 也可以编译,避免影响纯 C 的用户。不过从纯技术角度看,Linux 内核第二语言是一个有意义的探索。 |
22
zzz22333 19 小时 53 分钟前
@james122333 其实 Linux 主线也挺乱的了,太多厂商的信息了。
|
23
james122333 15 小时 10 分钟前 via Android
|
24
james122333 15 小时 9 分钟前 via Android
|