问为什么Linux模块API不向后兼容？

EN

Greg Kroah在这里写过这个主题：https://www.kernel.org/doc/html/v4.10/process/stable-api-nonsense.html。

除了一些关于编译C代码的技术细节外，他还提出了几个基本的软件工程问题，让他们做出决定。

Linux始终是一项正在进行的工作。发生这种情况的原因有很多：

• 新的要求出现了。人们希望他们的软件能做得更多，这就是为什么我们大多数人都在升级，我们需要最新和最伟大的功能。这可能需要对现有软件进行返工。
• 发现需要修复的bug，有时bug与设计本身有关，如果不进行大量的返工，就无法修复。
• 在软件世界中，新的想法和习惯会出现，人们会发现更容易、更优雅、更有效的方法来做事情。

这在大多数软件中是正确的。和任何未维护的软件都将缓慢而痛苦地死去。您要问的是，为什么那些旧的未维护的代码仍然有效？

为什么没有维护旧接口？

为了确保向后兼容性，需要维护旧接口(通常是“损坏的”和不安全的)接口。当然，从理论上讲，这样做是可能的，除非它确实会带来很大的成本。

格雷格·克罗-哈特曼写道

如果Linux必须确保它将保持一个稳定的源接口，那么就会创建一个新的接口，并且随着时间的推移，旧的、损坏的接口将不得不被维护，从而为开发人员带来额外的工作。因为所有的Linux 开发人员都是用自己的时间工作的，所以要求程序员免费做额外的工作是不可能的。

尽管Linux是开源的，但开发人员维护它的时间仍然有限。因此，人力仍然可以用“成本”来讨论。开发人员必须选择如何打发时间：

• 花费大量的时间来维护旧/坏/慢/不安全的接口。有时，在第一个实例中，这可能是编写接口所需时间的两倍。
• 处理旧的接口，并期望其他软件维护人员做好他们的工作维护他们自己的软件。

总的来说，绑定接口确实具有成本效益(对于内核开发人员来说)。如果您想知道为什么开发人员不花几个月和几年的时间从支付10美元中拯救其他人以获得新的wifi适配器.这就是原因。请记住，对于内核开发人员来说，这是时间/成本效益，而不一定对您或制造商具有成本效益。

虽然我为Linux内核贡献了一些(非常小的)补丁，但我并不认为自己是一个内核开发人员。然而，我知道的是：

一个为内核版本2.6.0.0编写的驱动程序，它比内核版本2.6.39中的大内核锁的消除早.

BKL是在Linux还是一个单处理器(单核、单线程)操作系统时创建的.一旦添加了SMP支持，开发人员就会意识到BKL在某一时刻将成为一个大瓶颈，但是只要系统中总共只有几个内核/线程，它就有点可以容忍了。但是对于在超级计算机中使用Linux的人来说，它首先成为了一个真正的问题，所以这项工作开始用更细粒度的锁定机制来代替所有需要BKL的东西，或者尽可能用无锁的方法。

在普通台式机和高功率笔记本电脑上可能有两位数的核数的现代计算机上，更不用说服务器，2.6.0向后兼容的内核模块API也需要实现BKL。

如果一个遗留模块说“我想要BKL"，那么内核的其余部分不知道模块计划如何处理它，所以向后兼容机制必须采用所有取代BKL的锁来覆盖所有的可能性。这将是一次大的表演热。此外，新的无锁方法还需要检查遗留锁--这从一开始就克服了无锁的问题。因此，即使没有实际加载遗留模块，向后兼容性机制的存在也会降低系统性能。

最近，当内核/用户空间边界被跨越时，幽灵/熔毁安全补丁对需要发生的事情做了很大的改变。在幽灵/熔毁修复之前编译的任何模块都可能不可靠，使用后Specre/熔毁内核。

就在两周前，当自动化应用安全更新时，我还在对一台需要手动供电循环的旧服务器进行故障排除。这种情况以前曾发生过几次，而且是可以复制的。我发现它有一个非常老版本的专有megasr存储驱动程序之前的谱/熔毁补丁，这是不包括在自动更新。在将驱动程序更新到当前版本后，问题就消失了。顺便说一下，这是在一个普通的RHEL 6.10系统。

我还看到服务器在加载专有的预谱/熔毁硬件监控驱动程序时崩溃，这些驱动程序带有后谱/熔毁内核。基于这一经验，我完全相信幽灵/崩溃修复需要被视为一个分水岭事件:内核和模块要么是修复前的所有版本，要么是修复后的所有版本；混合和匹配只会导致对待调用系统管理员的悲伤和午夜唤醒呼叫。

由于幽灵是一个CPU设计级别的问题，它是“一个不断给予的礼物”：一些人会找到新的方法来利用这些弱点，然后内核开发人员将需要找到阻止这些漏洞的方法。

这只是2.6.0.0兼容的遗留内核模块API需要解决的两个大问题。我相信还有很多其他的。

还有更有哲理性的一面。想想看:是什么使Linux成为可能？

其中很大一部分是开放式硬件规范。如果硬件规格是开放的，任何人都可以参加。由于操作系统的源代码是开放的，任何人都可以为每个人的利益作出贡献。如果您的驱动程序代码是开源的，您就不能将硬件编程规范作为您的商业机密。

Linux内核开发人员倾向于相信开源模型。这就是他们做出设计和开发选择的原因，因此硬件制造商参与的首选方式是开放源代码驱动程序，将其合并到主内核源代码发行版中，然后(只有到那时)您才能在维护它时受益于整个内核开发人员社区。

这为硬件设计者和制造商提供了一些激励，使之成为可能。如果你有什么要保密的东西，努力把它封装到ASIC中，或者如果你必须的话，可以把它封装到签名的固件中。(如果是后者，请授予他人重新分发固件包的权限。)

但是由于内核是开源的，内核开发人员不能完全阻止其他人单独维护专有驱动程序。但他们也没有动机去关心他们。

事实上，内核调试中的私有二进制驱动程序所带来的额外麻烦是内核开发人员不关心专有驱动程序开发的一个诱因：“它们使我的工作更加困难，为什么我应该做任何特别的事情来使他们的工作更容易呢？”

因此，内核开发人员通常作为一个组/社区来做对他们最有利的事情。如果这包括一些模块API的更改，那么就随它去做吧。第三方司机甚至没有进入方程式。