Linux 7.4 合并窗口：EDAC 以「AI 修复狂潮」为由，请求把四款老驱动标为无人维护
EDAC 维护者 10 月 19 日请求把四款老驱动标为无人维护，理由是 AI 生成修复的狂潮。驱动暂时保留，之后的内核版本才会删除。
Linux 7.4 的合并窗口在 10 月 19 日开启。当天，EDAC 维护者 Borislav Petkov 发给 Linus Torvalds 的拉取请求提议，把 i82975x、x38、xgene、i3200 四款老驱动标为「无人维护」（orphan）。EDAC 是 Error Detection and Correction 的缩写，指 Linux 内核里负责上报内存等硬件纠错事件的子系统。请求正文给出的理由是：这些驱动没人真正在用，又要应付「AI 生成修复的狂潮」，而且没人能测试这些驱动上的修复，所以「是时候让它们退役了」。
要点
- 这份 EDAC 请求共 14 个文件，新增 567 行、删除 24 行。请求里真正改变维护状态的是四个标题为「MAINTAINERS: Orphan drivers/edac/…」的提交。驱动代码仍留在树里，删除要等之后的内核版本。
- Miguel Ojeda 的 Rust 请求共 248 个文件，新增 17,297 行、删除 3,925 行。大头是把 zerocopy 库升到 v0.8.62（10 月 8 日发布），一次跨了 8 个版本。Ojeda 在正文里称这部分为「a mostly mechanical import」，即基本是机械导入。
- 截至 10 月 20 日（UTC），两份请求都没有进入 torvalds/linux 的 master。master 上没有 rust/kernel/mem.rs，i82975x 仍标为 Maintained。
背景
EDAC 请求出现在 Linux 7.3 发布之后。7.3 于 10 月 18 日发布（Linux 7.3 发布），7.4 的合并窗口随即开启。
删老驱动这件事，今年并不是第一次。Phoronix 在 4 月 21 日报道，Andrew Lunn 提交了一组补丁，要删掉一批 ISA 与 PCMCIA 时代的老网卡驱动，合计约 27.6k 行。他的理由是：「Now there are more newbies using AI and fuzzers finding issues, resulting in more work for Maintainers.」（现在有更多新手借助 AI 和模糊测试找问题，维护者的工作量随之增加。）Phoronix 认为 EDAC 的做法与之相似，区别在于这次先标为无人维护，删除留到之后的版本。
同一个邮件列表上还有另一条线。10 月 13 日，Linus Torvalds 贴出一组由 Claude Code 参与写成的 page cache 补丁，随后有评审者找到了其中的竞争条件（Linus 用 Claude Code 写内核补丁）。同一周，Phoronix 报道说，有人提交了取消「Assisted-by」标签要求的补丁。10 月上旬布拉格的维护者峰会上，与会者据称已就弃用这一要求达成共识。开源项目里也有类似的压力：Google 从 10 月 1 日起暂停了开源漏洞赏金的产品漏洞提交，称自动化提交大幅增加、绝大多数无效（Google 冻结开源赏金）。
事实部分
Rust 与 EDAC 两份拉取请求的基本信息如下。diffstat 取自邮件正文，主线状态是 10 月 20 日对照 GitHub 上的 torvalds/linux 核对的。
| 项目 | Rust 拉取请求 | EDAC 拉取请求 |
|---|---|---|
| 发出时间 | 10 月 18 日 | 10 月 19 日 |
| 发信人 | Miguel Ojeda | Borislav Petkov |
| 规模（diffstat） | 248 个文件，+17,297 / −3,925 | 14 个文件，+567 / −24 |
| 主要内容 | zerocopy 升到 v0.8.62；新增 mem、ratelimit 模块；KUnit 测试生成方式调整 | 四个 Orphan 提交；新增 dummy EDAC 驱动与 intel-bff 驱动 |
| 主线状态（10 月 20 日） | 未合入，master 上没有 rust/kernel/mem.rs | 未合入，i82975x 仍为 Maintained |
Phoronix 标题里的「17k」对得上的是新增行数。同一个请求还删掉了 3,925 行，净增约 13,372 行。IT之家 的标题写的是「引入约 1.7 万行 Rust 内核代码」，漏掉了删除的部分。
Phoronix 把四款驱动对应到具体芯片：i82975x 对应 Intel 975X Express 芯片组，x38 对应 Intel X38 MCH，xgene 对应 AppliedMicro 的 X-Gene SoC（X-Gene 3 后来用在了 Ampere eMAG 上），i3200 对应 Intel 3200/3210 芯片组。
各方说法
Petkov 的依据写在 EDAC 请求里：「At least there are no traces of usage on the mailing lists.」（至少邮件列表上没有使用的痕迹。）这是列表上的沉默，不是部署数据。请求也没有给出 AI 生成补丁的数量，「AI 生成」是维护者的描述，我们无法逐条核对。请求里其余的修复，它也称为「The now-usual AI-powered fixes」（如今常见的 AI 驱动修复）。
Phoronix 的 Michael Larabel 写道，这些驱动「很可能没有真实使用」（likely not seeing any real-world use）。
中文报道的覆盖很薄。IT之家 10 月 20 日的文章只讲 Rust 请求，全文没有提到 EDAC，并注明信息来自 Phoronix，所以我们能找到的 EDAC 报道只有 Phoronix 一家。Hacker News 上，以 EDAC 为关键词搜索 10 月 17 日以后的故事，返回 29 条模糊匹配，没有一条的标题或链接指向 EDAC；Rust 那篇 Phoronix 报道有一条帖子，5 分，没有评论。
EDAC 的理由和「Assisted-by」的讨论并不冲突。后者问的是要不要标注 AI 的参与，属于披露问题。请求原文谈的是修复的数量和无法测试的状况，没有谈 AI 写的代码质量。
编辑判断
对仍在这四款老平台上跑内核的人，第一天什么都不会变：驱动还在树里，代码没有任何变化。变化在于，这些驱动的修复将没有维护者来审，删除的时间也没有公布。如果你的机器还依赖其中一款，升级计划里应该把这一点算进去。
对内核开发者来说，更有用的单位是测试能力，而不是行数。Ojeda 说 Rust 请求的大头是 zerocopy 的机械导入，所以 17,297 行新增说明不了评审的工作量。EDAC 请求里真正的信号是那四个 MAINTAINERS 提交，而不是 567 行新增。
这篇报道的缺口在数字上。我们没有找到 EDAC 里 AI 生成补丁占多少的统计，也没有找到这四款驱动还有多少机器在用的数据。「没人用」是从邮件列表的沉默推出来的，判断可能出错。
接下来
EDAC 与 Rust 两份请求的后续有三件事值得盯着：
- 两份请求能否进入 7.4，取决于 Linus 在合并窗口里的处理。按内核的常规节奏，窗口结束时会发布 7.4-rc1。
- 四款驱动的删除要等之后的内核版本，Phoronix 没有给出时间。
- 取消「Assisted-by」要求的补丁，Phoronix 10 月 13 日报道时还在邮件列表讨论中。我们没有核实它之后的进展。