三位内核开发者描述了在内核上工作的真实感受，他们如何与其他公司的开发者互动，一些让他们恼火的事情以及如何入门。

像大多数 Linux 用户一样，我很少接触 Linux 内核的实际代码。当然，我看过它。我甚至在少数情况下自己编译过内核——有时是为了尝试一些新东西，或者仅仅是为了说我能做到（“Linux From Scratch”有点像成人礼）。

但是，除非你是 Linux 内核开发者之一，否则你很可能没有太多机会真正“深入了解”。

同样，我认为对于许多 Linux 用户（甚至是专业用户、系统管理员和开发者）来说，内核开发的狂野世界有点神秘。当然，我们有公开可用的 Linux 内核邮件列表 (LKML.org)，任何人都可以自由浏览最新的功能、讨论和（有时）恶作剧，但这只让人瞥见了作为内核开发者的一个方面。

而且，老实说，我们大多数人根本没有时间来筛选每天涌入 LKML 的无数拉取请求（以及由此产生的对这些拉取请求的讨论）。

考虑到这一点，我联系了三位内核开发者——他们都在当今一些最著名的 Linux 贡献公司工作——向他们提出了一些基本问题，这些问题可能会更好地了解成为 Linux 内核开发者到底是什么样的：他们的日常工作是什么样的，以及他们如何与其他公司的内核开发者合作。

这三位开发者（排名不分先后）

• Dave Hansen，英特尔系统软件产品首席工程师。
• Josh Poimboeuf，红帽企业 Linux 首席软件工程师。
• Jeff Mahoney，SUSE Labs 内核工程团队主管。

英特尔、红帽和 SUSE——Linux 内核代码的三大贡献者。如果有人知道成为内核开发者是什么样的，那就是他们了。

我向这三位都提出了完全相同的问题。他们的回答如下，完全未经修改。

Bryan Lunduke： 您从事 Linux 内核工作多久了？是什么让您入行的？

Dave Hansen（英特尔）： 我第一次接触 Linux 内核是大约 20 年前，为一个 IBM PS/2 上的八字符显示器编写了一个小型设备驱动程序。我在大学简历中提到了这个项目，这最终在 2001 年为我带来了一份在 IBM Linux 技术中心的工作。我在 IBM 开始了我的 Linux 内核专业工作。

Josh Poimboeuf（红帽）： 我第一次接触 Linux 大约是在 2001 年，当时我在 IBM 担任服务器固件软件工程师。IBM 最近拥抱了 Linux，我被安排在一个负责用基于 Linux 的新嵌入式 PowerPC 平台替换遗留专有固件的团队中。

一旦我发现了 Linux，我就被迷住了。我立即在我的笔记本电脑上安装了它。所有源代码都是免费提供的，你可以控制笔记本电脑上运行的每一行代码，这真是令人难以置信。而且，令人难以置信的是，它是免费的。

在 IBM，我最初从事硬件启动和 Linux 应用程序开发。但我一直对内核特别着迷。因此，我的好奇心逐渐引导我向下层堆栈工作。我的第一次真正的内核经验是在 2004 年开始编写设备驱动程序时。

到 2008 年，我已经是团队中的“内核专家”，负责将内核移植到我们的专有硬件，并解决现场发现的所有内核问题。这有点像在火中洗礼，但这是了解整个内核树的好方法。

内核太大了，以至于我的学习过程一直持续到今天。这始终是我最喜欢内核的地方之一。总有更多东西要学习。

现在我在红帽工作，在那里我做了更多上游工作。我从事各种各样的工作：实时补丁、objtool 静态分析工具、x86 unwinder、推测性 CPU 漏洞缓解等等。

Jeff Mahoney（SUSE）： 我从事 Linux 内核工作已经 20 年了。我最初在大学里开始接触它，因为我对系统软件很感兴趣。我碰巧买了一些没有驱动程序的硬件，我写了一个小的驱动程序。在从事内核工作之前，我是一名 UNIX 系统的系统管理员，然后我和一位同事决定尝试自己编写一个集群文件系统。结果证明，用于此目的的硬件对我们来说太贵了，所以我们最终为 ReiserFS 做出了贡献。这使我们两人都走上了从事 Linux 工作的职业道路。

Bryan： Linux 内核开发者的一天通常是什么样的？

Dave（英特尔）： 我的一天可能会有很大不同。唯一不变的可能是电子邮件——大量的电子邮件。可能是内部或外部代码审查，或者回答来自另一个英特尔团队或外部客户的问题。最好、最令人满意的一天是从一个问题或内核崩溃开始，并在一天结束时发布补丁。

Josh（红帽）： 了解内核开发者每天所做事情的多样性可能会令人惊讶。每一天——每一周和每一个月——都是不同的。这通常是“选择你自己的冒险”。

显然，内核开发者主要做的事情之一是编写代码。有时我可以（大部分时间）消失一周或一个月（或两个月！）来研究一个新功能。那些日子/周/月是我最喜欢的部分。

但编写代码只是其中的一部分。还有调试、阅读代码、协作、测试、代码审查、与代码相关的讨论、阅读论文、研究和会议。混合一下是好事。而且你可以与来自世界各地的非常聪明的人互动，这真的很有趣。

大多数交流通过电子邮件进行，但许多内核开发者也参加会议，如 Linux Plumbers Conference 或 Kernel Recipes。许多好的讨论发生在会议上。它们也有助于将面孔与名字联系起来，当你主要通过电子邮件与人互动时，这会产生很大的不同。

Jeff（SUSE）： 这是沟通、编码、构建和测试的混合。大量的电子邮件——错误报告、代码审查、设计讨论，无论是内部的、在公共邮件列表上还是在 IRC 上。

Bryan： 就您的团队所做的内核工作而言，有多少是与自己公司内部的其他人合作，有多少是与其他公司从事 Linux 开发的开发者合作？可能是以某种方式相互竞争的公司？

Dave（英特尔）： 由于我们的客户使用 Linux 的方式种类繁多，与上游内核合作是绝对必要的。几乎所有这些工作都会导致与来自其他公司的社区人士合作。在幕后也有很多工作在进行，以支持与社区的合作。社区中某人的一个很好的评论可能会导致我们花一周或一个月的时间来修改我们的工作。虽然我们可能在某一天没有在 LKML 上发送邮件，但我们正在积极地与社区合作。

Josh（红帽）： 这实际上因人而异。有些人 100% 的时间都花在上游与 Linux 社区合作。另一些人 100% 的时间都花在内部，回溯移植和解决 RHEL 中的问题。我们中的许多人介于两者之间，将时间分配在两个世界中。

红帽的政策是“上游优先”。因此，红帽内核中的任何功能或修复都必须首先被上游社区接受。这给了我们充足的机会与 Linux 社区合作。

Jeff（SUSE）： 这取决于我们正在做什么——错误报告通常由 SUSE 内部的开发者和支持团队处理。部分原因是合同，部分原因是实际情况。当我们发布产品时，我们选择了一个特定的内核版本并以此为基础构建。任何修复也必须针对该版本，而上游社区通常对这些不感兴趣。一旦我们创建了一个修复程序，如果该错误仍然存在于最新版本中，我们将在公共场合进行这项工作。

功能开发发生在公共邮件列表上，参与者可能在 SUSE 工作，可能在其他公司工作，或者可能是出于个人兴趣而做这件事。在 Linux 上工作最令人愉快的部分之一是，即使有来自数百家不同公司的开发者可能彼此竞争，我们也可以像在同一个团队一样进行协作。除了用于代码审查和讨论的邮件列表外，许多子系统都有 IRC 频道，开发者（和用户）可以在其中聊天讨论项目和社交。

Bryan： 当您需要在内核问题（如安全漏洞）上与其他公司（如英特尔、SUSE、红帽、Canonical、IBM 等）合作时，这是如何运作的？是否有既定的流程？

Dave（英特尔）： 实际上有两个互补的过程在发生。英特尔拥有正式的公司对公司沟通渠道，这对于协调业务方面的事情非常有用。安全方面的一个挑战是创建沟通渠道，以支持协同披露过程，同时支持正常的社区流程，如邮件列表。这两种途径都迅速成熟，并继续发展，以帮助我们应对不断变化的安全形势。

Josh（红帽）： 当存在禁运的安全漏洞时，我们确实有严格的流程来与其他公司进行安全协作。

幸运的是，这种禁运很少见，而且它们是我们正常运作方式的例外。我们通常一直与来自其他公司的开发者在 Linux 内核邮件列表上密切合作，无需特殊流程。

一个很好的例子是实时内核补丁。我在红帽的团队创建了 kpatch 技术，但与此同时，SUSE 的一个团队创建了 kGraft。我们没有继续采用竞争的方法，而是通过会议和邮件列表与 SUSE 团队密切合作，创建了 livepatch，事实证明，livepatch 是一项比 kpatch 和 kGraft 都更好的技术。

事实上，像这样的跨公司合作每天都在上游邮件列表中发生。这真的只是日常工作。我们的互动始终专注于什么对上游最有利。最终，对上游最有利的也是对依赖它的公司最有利的。这种独立于公司的态度强烈地反映在上游 Linux 文化中。

Jeff（SUSE）： 对于尚未公开的安全漏洞，我们的安全团队会与其他公司的对口部门协调。否则，除非有令人信服的理由不这样做，否则所有协作都在公共邮件列表上进行。在那里，流程是发布您的代码，倾听并回应审查和反馈，执行所需的更改，重新发布，并重复。

当反馈是积极的时，流程就完成了，子系统的维护者将（根据他们的时间表）拾取它，并将其拉入他们子系统的 git 仓库。然后维护者要求 Linus 将这些更改拉入主线仓库。

Bryan： 每个软件开发者都会对他们从事的项目感到恼火。您对 Linux 最恼火的事情是什么——您真正希望改变的事情是什么？

Dave（英特尔）： 我真的希望开发者能够专注于让审查人员的生活更轻松。首先，沟通您正在做什么、您为什么要这样做以及为什么它很重要至关重要。然后，确保代码及其支持注释尽可能地一目了然。我们常常只专注于确保代码能够运行，然后就收工了。对我来说，这只完成了一半的工作。

Josh（红帽）： 如果我有一根神奇的 Linux 魔杖，我会

1. 消除 CPU 推测——不再有 Spectre/Meltdown 类型的漏洞！
2. 消除对安全禁运的需求——但要明确的是，我认为在现实世界中这种禁运是必要的。
3. 更广泛地实现 Linux 内核开发人口的多样化。更多不同的视角可以产生更好的想法。我认为我们已经在朝着这个方向缓慢前进。

其中，第 1 项和第 2 项是不现实的，但也许我们可以实现第 3 项。

Jeff（SUSE）： 社区缺乏多样性，尤其是性别差距。女性在计算机科学领域普遍代表性不足，但在 Linux 内核社区尤其如此。已经有一些外展努力，但还需要做更多。

Bryan： Linux 内核到目前为止已经超过四分之一个世纪了。用软件术语来说，它当然存在很长时间了！您认为有必要在不久的将来替换它吗？如果是，用什么替换？如果不是，为什么？

Dave（英特尔）： 我并不真正认为 Linux 是一个 25 年前的项目。25 年前的 Linux 并不是服务器、路由器或手机上的默认操作系统。没有必要替换像 Linux 这样不断变化、增长和改进的东西。

Josh（红帽）： 如今，技术趋势变化无常，大多数技术的生命周期都很短。但我不认为 Linux 会消失。它的真正优势在于其开发模式。它并不完美，但这仍然是我见过的以规模化方式生产软件的最佳方式。如果看到 Linux 在未来四分之一个世纪里蓬勃发展，我不会感到惊讶。

Jeff（SUSE）： 虽然该项目已经有 25 年以上的历史，但它并没有停滞不前。内核本身不断发展以满足新的需求。每年都有新的用户加入 Linux 社区。在过去的十年中，每个版本中内核的提交次数都在 10,000 到 15,000 之间。社区仍在增长。我不认为它会在短期内被取代，但它将继续发展。

Bryan： 您会对考虑加入 Linux 内核开发的人们说些什么？

Dave（英特尔）： 请务必加入！Linux 对像英特尔这样的公司来说正变得越来越重要。找到具有内核技术技能和驾驭社区必要技能的人才是一项挑战。加入社区最成功的人是那些有问题要解决的人。也许是 Linux 不支持的某些设备，或者是笔记本电脑上让你抓狂的错误。那些带着没有解决明确问题的补丁而来的人通常很难让这些补丁被接受。

Josh（红帽）： 首先，我想说的是，找到一种方法投入进去，看看你是否喜欢它。

一个好的入门方法是选择你感兴趣的内核的一个小领域，并全身心投入成为该小段代码的专家。阅读代码直到你理解它。调整它，看看它如何影响你的系统。开始审查邮件列表中与之相关的补丁。过一段时间，你就会开始看到补丁的机会，比如错误修复或代码改进。

当你最终发布补丁时，不要对你的代码过于执着。尽量不要把反馈放在心上。我们的共同目标是生产最好的代码。犯错是可以的。放下你的自我，保持谦虚，保持尊重，并以开放的心态倾听反馈，并尝试从中学习。这就是代码变得更好的方式。它也有助于你赢得社区中其他人的尊重。

内核开发可能需要大量的耐心、谦逊和毅力。代码被丢弃或多次重写是很常见的。这个过程有时看起来效率低下。但在我的经验中，最终结果总是比任何专有开发都能产生的结果更好。

内核代码库非常庞大，因此深入研究你从未见过的代码将是很常见的。每当你对某件事的工作原理有疑问时，答案总是在代码中的某个地方。熟悉 cscope。对于 vim 用户，我建议使用 vim cscope 插件。

此外，还要提高你的书面沟通技巧，因为你的大部分非编码时间都将花费在电子邮件上。当然，学习如何让你的代码易于他人阅读也非常重要。

最后，找到导师（或多位导师）可能很有价值。我从来没有正式的导师，但我很幸运在过去的几年里有许多更有经验的人指导我。

Jeff（SUSE）： 这可能非常有趣，但入门需要付出一些努力。从你感兴趣的东西开始，找到一些小问题来修复，并发布你的工作。阅读并理解流程。倾听并回应反馈。经验丰富的开发者通常愿意花一些时间帮助新开发者，如果他们愿意倾听的话。