25年Linux内核开发经历总结出来的九条经验

最新推荐文章于 2024-09-16 20:42:39 发布

钱曙光

最新推荐文章于 2024-09-16 20:42:39 发布

阅读量4k

点赞数 4

文章标签：参数 new for 设置元素

本文链接：https://blog.csdn.net/qiansg123/article/details/80129421

版权

原文：9 lessons from 25 years of Linux kernel development
作者：Greg Kroah-Hartman
翻译：雁惊寒

Linux内核社区在2016年庆祝了成立二十五周年纪念，许多人来问我们这个项目经久不衰和成功的秘诀。我一般会先笑笑，然后开玩笑地说，我真的不知道已经经历了25年。这个项目一直都面临着分歧和挑战。但是，严肃地说，我们能够做到这一点与社区在反思和改变上的能力有着很大的关系。

大约16年前，大多数内核开发人员互相之间从来没有见过面，我们只是通过电子邮件进行联系，所以Ted T’so提出了内核峰会的想法。现在，内核开发人员每年都会聚在一起解决技术问题，更重要的是，回顾一下在过去的一年里我们做了哪些对的事情，又犯了哪些错误。开发人员可以开诚布公地讨论相互之间如何进行交流以及开发流程如何运作。然后，我们会改进流程，我们会开发像Git这样的新的工具，不断地改变我们的合作方式。

虽然我们现在尚未完全认识清楚Linux内核成功的所有关键原因，但目前还是有一些经验值得拿出来分享的。

1. 更短的发布周期很重要

在Linux项目的早期阶段，内核的每个主版本需要好几年发布一次，这意味着用户需要等待很长时间才能享受到新功能，这对于用户和经销商来说是相当令人沮丧的。而且，更重要的是，这么长的周期意味着需要一下子集成大量的代码。把这么多代码合入一个版本里，压力也是很大的。

更短的周期可以解决所有这些问题。新代码能够在更短时间内合入到稳定版中。将新代码集成到几乎稳定不变的基线版本上，使得能够在对系统产生极小影响的情况下引入根本性的变化。开发人员知道，如果他们错过了这个发布周期，两个月内还会有另外一个，所以他们很少会过早地合入代码。

2. 流程的扩展需要一个分布式的分层开发模型

很久以前，所有的变更需求都会直接转到Linus Torvalds手中，但这很快就被证明是不合适的，因为没有哪个人可以全面掌握像操作系统内核这么复杂的项目。很早的时候，内核不同领域的维护者们就提出了一个想法，就是把内核的其中一部分分配给熟悉该领域的人。例如，网络、无线、像PCI或USB这样的驱动程序子系统、或者像ext2或vfat这样的文件系统。然后再扩展到由数百名维护人员负责代码审查和整合，从而使得能够在不牺牲产品质量的情况下，在每个发布的版本中都包含成千上万的变更。

3. 工具的重要性

内核开发一直在试图扩大开发人员的范围，直到BitKeeper这款源代码管理系统出现，几乎在一夜之间社区的做法发生了改变，而Git的出现带来了又一次的飞跃。如果没有合适的工具，像内核这样的项目将无法正常运转，从而会被自身的重量压垮。

4. 强大的舆论导向模式很重要

一般来说，如果一个开发大咖拒绝了某个提交上来的变更，那么这个变更将不会被合并进去。如果开发人员发现自己在几个月前提交的代码在邮件列表中被拒绝了，那是非常令人沮丧的。但这也保证了内核开发可以适应大量的用户和问题。没有哪个用户社区能够以牺牲其他群组为代价而进行变更。我们有一个可以支持从微型系统到超级计算机的代码库，它可以应用在很多场景上。

5. 强大的“无回归”规则也很重要

大约在十多年前，内核开发社区承诺，如果给定的内核在特定的环境中能正常运行，那么所有后续的内核版本也能在这个环境中正常运行。如果社区发现某个变更导致了其他问题的出现，他们会很快地解决这个问题。该规则承诺用户：系统升级不会破坏他们原来的系统。因而，维护者很愿意在开发新功能的时候延续这个内核。

6. 公司参与到开发流程中来是至关重要的，但没有哪家公司能够主导内核开发

自2014年12月版本号为3.18的内核发布以来，有将近500家公司的大约5062名个人开发者为Linux内核做出了贡献。大多数开发人员因为他们的工作而得到了报酬，而他们所做的变更是为他们所在的公司服务的。但是，尽管任何一家公司都可以根据具体需求改进内核，但是没有哪家公司可以主导开发去做伤害别人或者限制内核功能的事情。