众所周知，向来脾气火爆、直来直去的 Linux 之父 Linus Torvalds，对代码质量有着严苛的要求，尤其是要合并到 Linux 内核的代码，更是容不得半点瑕疵和敷衍。

可就在 Linux 7.0 内核的开发进程中，一批计划合入的 MMC 相关代码修改，却直接撞了枪口——被 Linus 接连用“完全是垃圾”、“没经过测试的破烂”狠批，毫无情面地全部驳回，原本为 Linux 7.0 准备的一众 MMC 子系统优化，也因此彻底无缘该版本。

MMC 是什么？

Linux MMC（MultiMediaCard）子系统是内核中负责管理 MMC、SD 及 SDIO 总线协议的驱动框架。它不仅驱动 eMMC、SD 卡等存储设备，也驱动通过 SDIO 接口连接的非存储外设，如 Wi-Fi 模块、蓝牙适配器等。手机、嵌入式设备、开发板乃至部分服务器设备中的存储及无线通信部件，都可能依赖这一机制。

它负责设备初始化、协议处理以及读写调度等底层工作。虽然普通用户很少直接接触这一层，但在实际系统运行中，它是存储栈里不可或缺的一部分。

Linus 怒拒 Linux 7.0 中的 MMC 代码修改

这次子系统维护者原本计划给 Linux MMC 做一波升级，其实包含了一些颇有看点的改动，例如：

• 为通过 SDIO 连接的 NXP IW61x WiFi 芯片添加设备 ID 支持；

• 针对部分 Kingston eMMC 优化安全擦除和 TRIM 操作；

• 对 DW_MMC 代码进行清理；

• 在 mtk-sd 驱动中新增对联发科 MT8189 的支持，以及对多个 SHDCI 驱动的更新。

从功能层面看，这些改动并不算激进，更像是一次常规迭代。

问题出在代码本身以及流程上。

按照内核社区长期形成的惯例，子系统更新在向 Linus 发起 pull request 之前，应当先进入 linux-next 仓库进行整合测试。linux-next 的作用，是在主线合入前发现跨子系统冲突、编译问题以及集成错误。

然而，这次的 MMC 更新到了 Linus 手中时还存在一堆问题。

Linus 在邮件伊始直接怒斥道：“这些改动完全是垃圾，甚至连编译都过不了。看起来它们根本没有进过 linux-next，也没有做过任何构建测试。”

紧接着，他似乎是耐着性子一步一步告诉子系统的贡献者这段代码究竟错哪了：

当 CONFIG_MULTIPLEXER=m 时，我们会构建这个 core.o 文件：

但在 include/linux/mux/consumer.h 里你却写了：

这个条件在这里并不会成立（因为实际被定义的是 CONFIG_MULTIPLEXER_MODULE），结果就会引发一连串类似下面这样的错误：

因为 mux/consumer.h 头文件里已经定义了那个占位用的封装函数。

Linus 的“代码”洁癖

其实熟悉 Linux 社区的人都知道，Linus 对代码质量的要求向来严苛，这次的操作其实一点都不意外。Linux 作为全球使用最广泛的开源内核，从服务器、手机到嵌入式设备，都有它的身影，内核代码的稳定性和可靠性直接关系到无数设备的正常运行。

而 Linux-next 这个测试环节，就是内核代码的“第一道安检”，能提前发现编译、兼容性问题，避免有问题的代码进入正式版本。这批 MMC 代码不仅没走安检，还自带一堆错误，显然触碰了 Linus 的底线。

对此，Linus 的态度也很明确：

「我不想看到你再发什么“修复版”的 pull request。这件事完全不可接受，在这个合入窗口期间，我不会再从你这里拉取任何东西。

别再给我发那些没进过 linux-next、连最基本检查都通不过的未测试垃圾代码。

你可以在 7.1 周期再试一次——前提是它真的进过 linux-next，并且经过了正确的测试。」

回看过往，Linux 内核每个版本周期都会发生类似的“临门刹车”事件。对外界来说，这看起来像是一次“怒批”；对长期参与内核开发的人来说，这更像是例行的流程纠偏。

开放协作并不等于放松标准。正是这种对流程和质量的坚持，才让 Linux 主线在数十年高频迭代中保持相对稳定。

参考：

https://www.phoronix.com/news/Linux-7.0-No-MMC-Changes

https://lore.kernel.org/lkml/CAHk-=wgnRQiKqWVrO_uF1btYM2K8r8xL95RGdKU3QLe8B58nrw@mail.gmail.com/