C、Rust混合用被批为Linux的“癌症”,Rust开发者逼Linus“站队”失败后愤然辞职

360影视 2025-02-08 18:04 3

摘要:自 Linux 内核长期以来由 C 语言构建起步,直到 Rust 这股新兴力量悄然涌入,编程语言之争这把“火”,现如今不仅“烧”到了全球主流开源操作系统 Linux 的中心,还将 Linux 原有的维护者与 Rust 开发者推向了前所未有的对立面。

整理 | 屠敏

出品 | CSDN(ID:CSDNnews)

自 Linux 内核长期以来由 C 语言构建起步,直到 Rust 这股新兴力量悄然涌入,编程语言之争这把“火”,现如今不仅“烧”到了全球主流开源操作系统 Linux 的中心,还将 Linux 原有的维护者与 Rust 开发者推向了前所未有的对立面。

在一些 Rust 开发者看来,Rust 是安全语言的象征,在 Linux 内核中引入此语言无疑可以提高系统的性能、安全性。

然而,这一说法并未得到 Linux 内核维护者的认可,他们反而担心,多种语言的使用会让这个超级开源项目的维护变得更加困难,其甚至直言——Rust 与 C 语言的混合代码在 Linux 中就是“癌症”。

争论之下,Linux 之父 Linus 出面回应、核心开发者愤而辞职选择从此视而不见听而不闻...

Linux 内核维护者 vs Rust 开发者的口舌之争

其实 Rust for Linux 项目推进起来已有几年的时间,此前在 Linux 6.13 内核的“char/misc”模块合并中,新增了对 Rust 的支持,使得开发者能够使用 Rust 编写 misc 驱动程序,这是一些良好的开端。

不过,期间也出过一些“意外”,如去年 9 月,微软软件工程师也是 Rust for Linux 的核心维护者 Wedson Almeida Filho 官宣自己退出 Rust for Linux 这一项目,给出的理由是——已经疲于应对社区内越来越多与技术毫无关系的“废话”了,但好在此后项目仍在持续推进。

至于此次如文章伊始所述的 Linux 内核维护者和 Rust 开发者公然“互怼”又是为哪般?

具体看来,还是因为一场技术争议引发的口舌之争。

就在上个月,有人在 Linux 内核中带来了一个提案——想让用 Rust 写的设备驱动能够调用 Linux 内核中用 C 写的一个重要功能(DMA)。

具体来说,在 Linux 系统中,设备(比如网卡、显卡等)有时需要直接访问计算机的内存,而不经过 CPU 的干预。这种方式叫做直接内存访问(DMA, Direct Memory Access)。为了让设备能够使用 DMA,操作系统需要做两件事:

分配一块内存:这块内存是设备可以直接访问的。

映射这块内存:告诉设备这块内存的物理地址,这样设备才知道去哪里读写数据。

在 Linux 内核中,有一个专门的 API 叫做 DMA API,它提供了一些函数来帮助完成这些任务。其中一个重要的函数是 dma_alloc_coherent,它的作用是:

分配一块内存,并且保证这块内存是“连续的”(设备通常需要连续的内存块)。

同时,它会把这块内存的物理地址映射给设备,这样设备就可以直接访问这块内存了。

基于此,有人在 Linux 内核中提交了一个补丁,目的是让 Rust 编写的驱动程序也能使用这个 dma_alloc_coherent 函数,这样 Rust 驱动程序也能像 C 语言编写的驱动程序一样,使用 Linux 内核提供的 DMA 功能,从而更高效地处理设备与内存之间的数据传输。

然而,这个提议遭到了 Linux 内核维护者 Christoph Hellwig 的强烈反对。Hellwig 明确表示,他不希望在内核的 DMA 部分看到 Rust 代码。

实际上,这个补丁只是将代码添加到了一个不同的地方(rust/kernel),而不是直接改动 DMA (kernel/dma)部分。

Hellwig 的拒绝让很多 Rust 开发者们感到郁闷,对此,Rust for Linux 项目的首席开发者 Miguel Ojeda 出面请求 Hellwig 给出一个替代方案。

Hellwig 回应道:“把包装器放在你们自己的代码里,而不是让别人为你们的事情受苦。”

因为是在邮件列表的回应,所有开发者都可以看到,对此,Red Hat 的软件工程师 Danilo Krummrich 直接质问 Hellwig,「你们自己的代码是什么意思?是不是在每个驱动程序中都重复了?否则,rust/kernel/dma.rs 看起来合理,对吧?」

Hellwig 接着表示:“DMA API 的接口应该保持在可读的 C 代码中,而不是用奇怪的绑定来实现,这样它才可以被 grep 搜索并且更易于维护。”

此外,Hellwig 也明确表示他根本不愿意处理 Rust 代码。他写道:“不要强迫我处理你们这门时髦的语言。维护多语言的项目很痛苦,我没有兴趣去处理。如果你们想用的不是 C 语言,像汇编语言或 Rust,你们自己写 C 接口,自己解决语言不匹配的问题,反正我不管。”

Red Hat 的软件工程师 Danilo Krummrich 解释称,并没有人要求你处理或者维护这段 Rust 代码。Rust for Linux 项目正在创建 Rust 代码,它将 C API 抽象化,供所有 Rust 驱动程序使用,并由 Rust 开发者来维护。

换句话说,内核中的 C 代码保持不变,而 Rust 驱动程序通过抽象层来使用这些 C 代码,这些抽象层由 rust/kernel 中的团队集中维护,整体上比每个驱动程序自己编写 C 语言绑定要好。

但 Hellwig 似乎不愿意让 DMA 的 Rust 抽象层单独维护,甚至不应该在 Linux 源代码树 rust/kernel 中维护。他怒斥道:

“如果你们想让 Linux 因为跨语言的代码库变得无法维护,那就让你们的驱动自己去做吧,而不是把这种‘癌症’传播到核心子系统中。(这里说的‘癌症’显然是指跨语言的代码库,而不是 Rust 本身,只是为了避免被激起争议)”

此话一说,这让人想起 2001 年,前微软 CEO 史蒂夫·鲍尔默曾将 Linux 比作癌症。他当时说:“Linux 就像一种癌症,它会在知识产权的层面附着到它接触的每一个东西。”那时 Linux 还没有扩展到 Windows 子系统中。而现如今 Windows 开始深度集成 Linux 子系统,微软深度拥抱了开源。

Hellwig 继续论述说,让其他人单独维护 Rust 的抽象层来处理 DMA 的内存分配器,并不会改善问题,反而会妨碍内核的可维护性:

“每引入一种新语言,就会大大降低内核作为一个整体项目的可维护性。Linux 之所以能生存这么久,是因为它没有内部边界,而引入另一种语言完全破坏了这一点。你可能不喜欢我这么说,但我会尽全力阻止这种做法。这不是因为我讨厌Rust。虽然它不是我最喜欢的语言,但它绝对是新兴语言中最好的之一,我鼓励人们在适合的情况下用于新项目。我只是不希望它出现在我需要维护的大型 C 语言代码库中。”

几轮辩论之后,Red Hat 的软件工程师 Danilo Krummrich 认为:

Hellwig 作为一名维护者,他的一些举措超出了维护者的工作范围,即:

根据个人喜好,任意限制某个实体对公共内核 API 的使用。

为此,他和 Asahi Linux 项目负责人 Hector Martin 纷纷请求 Linux 之父 Linus Torvalds 出面解决这一问题。

Asahi Linux 项目负责人 Hector Martin 在邮件中写道:

我的看法:如果 Linus 没有在这个讨论中给出权威的答复,Miguel 和其他 Rust 的开发者应该在代码经过审查并准备好后,直接合并这部分内容,不必理会 Christoph Hellwig 明显想要破坏项目的行为。

如果 Linus 拒绝合并,那么 Christoph 说的就无关紧要了。

如果 Linus 不合并,R4L 项目基本上就会死掉,除非 Linus 或 Christoph 采取行动。其他的讨论只是绕圈子。

Rust 开发者们:请不要浪费时间和精力去纠结这种戏剧性的事情,这不值得。要么 Linus 喜欢,要么他不喜欢。其他的都是少数破坏者维护者故意制造的干扰,他们想通过打击你们的士气来让你们放弃,因为他们知道自己终究会在历史中处于失败的一方。旧的固守阵地的维护者再怎么破坏,也无法阻止世界向内存安全语言的方向发展。

顺便说一句,我认为 Christoph 的“癌症”言论足以成为违反行为规范的理由,但我怀疑不会有任何相应的处理。

Linus 回怼:我根本不想参与你的社交媒体舆论战

殊不知,Hector Martin 的这一则邮件直接将 Linus 推到需要做出二选一决策的”边缘“。

面对 Hector Martin 呼吁 Linus “发表权威回答”以解决设备驱动的僵局,并支持通过“社交媒体羞辱”来反击 Linux 维护者对 Rust 代码的敌视,Linus 对此方法予以否定。

Linus 极其礼貌但毫不客气地回应 Martin:

如果在社交媒体上羞辱他人没有效果,那就告诉我,还有什么方法有效,因为我已经没有其他办法了。

你能不能接受一个事实,也许问题出在你自己身上?

你以为你知道得更好,但目前的流程是有效的。

它有问题,但问题是生活的一部分。没有完美的东西。

不过,我必须说,社交媒体的“围攻”让我根本不想再和你们的做法有任何关系。

因为如果我们在内核开发模式中有问题,那么社交媒体绝对不是解决方案。就像它根本不是政治问题的解决方案一样。

技术补丁和讨论才是关键。社交媒体围攻——谢谢,但不需要。

来源:CSDN

相关推荐