Linux 6.17内核的RISC-V架构更新因提交过晚且部分代码质量不佳，被Linus Torvalds否决。Torvalds批评部分代码为“垃圾”，并强调了及时提交和代码质量的重要性。此次否决意味着RISC-V相关功能需等到Linux 6.18版本再进行尝试。此事件也引发了关于内核开发流程和代码规范的讨论，尤其是在合并窗口期间的提交策略。

🚫 Linus Torvalds 否决了 Linux 6.17 内核中 RISC-V 架构的更新，理由是代码提交过晚且部分内容质量低下。他明确表示，类似“垃圾”的代码不应在合并窗口后期提交，尤其是在他本人即将外出旅行的情况下。

📉 Torvalds 对提交的 RISC-V 代码中的一个名为 `make_u32_from_two_u16()` 的“辅助函数”表示强烈不满。他认为该函数不仅无用且难以理解，而且其设计（特别是词序问题）比直接使用位移操作更糟糕，并将其添加进通用头文件污染了其他代码。

⏰ 此次否决意味着 RISC-V 架构的更新无法在本周期内集成到 Linux 6.17 版本中，需要等到今年晚些时候的 Linux 6.18 版本再次尝试。Torvalds 强调，未来将不再接受延迟提交的拉取请求，并且通用头文件不应被不相关的“垃圾代码”污染。

⚖️ Torvalds 强调了内核开发中代码质量和提交时间的重要性。他明确指出，在合并窗口关闭前一天提交大型拉取请求，并期望维护者因繁忙而忽略问题，这种策略是无效的。开发者必须遵守早期提交规则，并确保代码的质量和规范性。

⚠️ 该事件也间接反映了 Linux 内核社区在代码审查和合并流程中的严格性。Torvalds 作为项目领导者，对于代码质量和开发流程有着极高的要求，任何不符合标准的提交都可能被拒绝，以维护整个内核的稳定性和可维护性。

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 再次尝试。