Linus Torvalds 已根据其权力否决了Linux 6.17内核中 RISC-V 架构的变更。RISC-V 更新将不会在本周期内落地，需要在今年晚些时候再次尝试 v6.18 版本。Linus 认为至少部分提议的 RISC-V 代码是"垃圾"，而且在合并窗口期间提交得相当晚。

直到周五，RISC-V 代码更新才被提交到 Linux 6.17 合并窗口。Linux 6.17 合并窗口预计将于周日结束，届时将发布 Linux 6.17-rc1 版本。该内核的提案包括：将 RISC-V IOMMU 添加到基于 ACPI 的系统支持中；支持 ACPI BGRT，以便在启动时显示供应商徽标；提供勘误表解决方案；支持 Xmipsexectl 扩展；从设备树读取 MMU 类型；改进字节序交换例程的性能；支持 kprobetrace；支持 MPXY 和 RPMI SBI 扩展；以及支持用户空间进程的控制流完整性。

但 Linus Torvalds 拒绝了针对 Linux 6.17 的此拉取请求，理由是合并窗口提交较晚，尤其是在他本周出国旅行的情况下。他对此合并请求中包含的一些代码感到不满。

Torvalds今天早上在邮件列表中写道：

“不。这是垃圾，而且提交得太晚了。我要求尽早提交拉取请求是因为我正在旅行，如果你不能遵守这条规则，至少要把拉取请求做得*好*一些。”

这会增加各种垃圾，这些垃圾并非 RISC-V 特有的通用头文件。

我说的“垃圾”是真的。这些东西谁也不应该发给我，更不用说在合并窗口后期了。

比如这个疯狂而毫无意义的 make_u32_from_two_u16() “辅助函数”。

它让世界变得更糟了。它是无用的垃圾，让任何用户都无法理解，而且比不使用那个愚蠢的“辅助函数”*更糟糕*。

如果你把代码写成“(a << 16) + b”，你就知道它的作用以及哪个是高位字。也许你需要添加一个强制类型转换，以确保“b”的高位不会污染最终结果，所以也许它不会很“漂亮”，但至少不会……既错误又难以理解。

相反，如果你写 make_u32_from_two_u16(a，b)，你根本不知道它的词序是什么。换句话说，你只是把事情弄得*更糟*了，而且你把那个“辅助函数”添加到一个通用的非 RISC-V 文件中，而人们显然应该用它来让*其他*代码也变得更糟。

所以不行。这种事情需要改正。它不会出现在通用头文件中，而且在合并窗口后期也绝对不会发生。

你已收到通知：不再有延迟的拉取请求，RISC-V 树之外也不再有垃圾代码。

现在，我*希望*RISC-V 部分内部没有垃圾代码，但这是你的选择。但通用头文件中的内容不会被乱七八糟的东西污染。在合并窗口关闭前一天发送一个大型拉取请求，指望我太忙而无暇顾及，这不是一个成功的策略。

所以你可以在6.18. 在合并窗口的早期阶段。并且没有垃圾。

因此，RISC-V 功能代码将不得不在今年晚些时候针对 Linux v6.18 再次尝试。