构建红帽企业 Linux v. 3
很多人对构建企业级 Linux 发行版所需的幕后工作知之甚少。事实上，这个过程在很大程度上可以被认为是理所当然的，这实际上是一种赞扬。本文旨在让您了解我们交付红帽企业 Linux v. 3（企业 Linux v. 3）所使用的方法。正如您将看到的，我们一路上面临着许多挑战。但话又说回来，如果这很容易，那就不会那么有趣了。
在整篇文章中，重点是如何将这个版本组合在一起的。本文主要讨论了企业 Linux v. 3 中使用的内核的开发。内核只是整个发行版的一小部分，它是控制底层硬件和系统资源的部分。其他团队面临的挑战同样艰巨，例如编译器工具、安装程序、数百个应用程序包、文档和测试等项目。这些项目中的每一个都是由才华横溢的个人开发的。
请允许我首先指出，我们在红帽公司与行业内的主要合作伙伴建立了牢固的关系。尽管合作伙伴的匿名性在这里受到保护，但我相信他们可以识别出自己在故事中的位置，并认识到这完全是出于幽默。
专有 UNIX 操作系统已经设定了很高的客户期望，计划从 UNIX 迁移到 Linux 的客户不希望采用无法提供相同水平的稳健性、质量、支持和兼容性的技术。商业用户需要稳定性和可靠性。在某些情况下，这意味着尖端技术不适合包含在产品中。用户还希望能够在广泛的架构和硬件组件上运行，从而实现 Linux 避免专有厂商锁定的目标。支持需要以持续多年的维护形式提供，包括安全和错误修复，以及增量硬件支持和有价值但不会破坏稳定性的功能增强。
新版本的启动始于确定目标功能集。除了强烈的意见之外，红帽公司第二丰富的商品就是功能请求。它们来自四面八方，例如永不满足的独立硬件/软件供应商、苛刻的大客户和小客户，以及红帽遍布全球的销售和服务支持组织。此外，红帽工程部门内部也产生了许多想法，范围从性能和可用性增强到关于如何组织产品集的营销提案。
显然，我们没有无限的开发人员资源，因此主要的挑战是选择这些想法中最好的。另一个关键的功能验收标准是符合上游 Linux 的方向，这对于兼容性以及保持内核精神至关重要。内核精神由 Linus Torvalds 监管的 kernel.org 树体现，并包含来自世界各地的贡献。
以下是我们在需求收集中面临的一些具有挑战性的情景示例
我们要求每个合作伙伴提交一份规模合理的十大列表。一个合作伙伴的要求以一个两英寸厚的活页夹的形式提交。这本活页夹被亲切地称为“圣经”。我第一次接触到这本“圣经”是它被“砰”的一声扔到我的办公桌上。当我看到它时，我发誓我的心也“砰”了一下。
那些更精通数学的合作伙伴确实内化了十大列表的概念。然而，大多数人最终都使用了一种熟悉 TCP/IP 网络的你们应该认识到的策略——滑动窗口协议。它的工作方式是，一旦您的任何功能被接受，这些功能就会从堆栈顶部弹出，从而为功能 11、12 和 13 腾出空间，使其突然成为灾难性问题。
以下是来自硬件供应商的代表性功能列表示例
在 x86 上支持超过 32GB 的内存。
支持超过 8 个 CPU。
支持我们的新型 XYZ100 系列计算机。（这是一个经过巧妙伪装的多功能请求；其背后是一系列必需的设备驱动程序、PCI ID 和安装程序挂钩。）
更新的 I/O 适配器驱动程序。（这最终变成了关于它指的是哪个更新版本的意见分歧）。
集成对供应商专有基板管理软件的支持。（一个常年列入清单的项目，但始终被拒绝，这让请求者感到惊讶。）
编译器优化以匹配最新的芯片组。
为我们的 CD-ROM 驱动器提供 USB 支持。（需要这样做是因为该驱动器是脑残的，不符合规范——当然，最初的功能请求中没有这种微妙之处。）
支持超过 128 个磁盘。
然后，通常有以下隐含的要求
所有这些功能请求都适用于多种架构，包括 x86、AMD64 和 Itanium 2。
哦，顺便说一句，我们还希望将此功能向后移植到之前的企业 Linux v. 2.1 版本。
无数的外部请求要求专有添加或挂钩。在开源传统中，这是我们一直不得不拒绝的事情。
对于企业 Linux v. 3，最初的一组请求功能大约有 500 项。这些功能都已输入到我们的功能跟踪工具 Featurezilla 中，它实际上是 Bugzilla 错误跟踪工具的衍生产品。图 1 显示了 Featurezilla 中的几个项目。为了表明玩笑是双向的，一位合作伙伴有一位业务经理，名叫 Paul，为了保护无辜者，姓名已更改。他将列表作为文本文件管理，但在他的公司，该列表被称为 Paulzilla。
图 1. 功能跟踪工具 Featurezilla 列出了功能请求及其状态。
我们召开了无数次痛苦的内部会议，以确定优先级并艰难地处理全部 500 个项目。从这个优先排序的列表中，工程经理们开始努力将列表缩减到他们的团队成员可以人为实现的可管理集合。最终，协商后的列表远远超过了开发团队可以合理实现的任何目标。但是，这就是红帽的方式，而这仅仅是故事的开始。
为了保持趣味性，除了必须为红帽企业 Linux v. 3 开发制定积极的时间表外，还需要付出大量努力来支持企业 Linux v. 2.1 维护流。在企业 Linux v. 3 发布时，v. 2.1 已经发布了 15 个月。由于我们为企业 Linux 系列中的版本提供五年生命周期，因此我们不能简单地放弃企业 Linux v. 2.1 的支持和维护工作。我们的合作伙伴在维护流中提出的要求形成了一个有趣的悖论。当谈到维护流的目标时，似乎所有合作伙伴和知名客户都在唱反调。“什么都别改！我正在生产环境中使用这个版本。别打乱我的计划”，紧接着是“我真的需要这个功能，而且是立即需要。快点给我，但别放任何其他东西。”
最终，这一切都归结为仔细的个案风险/收益评估。在内部，我们在工程级别审查功能和错误修复提案。要用我的文学才能来传达就纳入跨越风险/收益界限的功能或错误修复所进行的意志坚强和充满激情的辩论，这远远超出了我的能力。
有些人误以为红帽只是从上游开源社区中随意收集一些零散的东西，贴上红帽的名字，就称之为产品。事实是，红帽工程师贡献了很大一部分上游（例如，2.4 和 2.6）内核开发。这些内核开发人员所表现出的生产力、知识广度和掌握大量内部和外部通信的能力令人震惊。他们真的是世界一流的，能与他们共事令人感到荣幸。但不要告诉他们这些，免得他们得意忘形。
图 2. 红帽公司的内核开发人员，从左到右：Larry Woodman、Dave Anderson 和 Rik van Riel。
除了被拉回到企业 Linux 内核中的大量上游增强功能外，还在内部开发了大量增强功能，以满足产品需求。作为一家开源公司，所有内核增强功能都可供整个社区使用。这些更改中的绝大多数最终都被纳入上游。
企业 Linux v. 3 中的内核主要基于 2.4.21 内核，但它从更新的 2.6 内核中向后移植了大量功能。考虑到 2.6 内核尚未稳定，只有被认为商业就绪的关键功能才有可能向后移植到企业 Linux v. 3 中。这里有一个关于如何真正激怒红帽内核开发人员的小技巧：说这样的话，“所以，你们只是发布了库存的 2.4.21 内核；对吧？”
构建企业 Linux v. 3 内核最艰巨的挑战是要求为七种不同的架构提供支持，并且这些架构的内核都必须从一个通用源代码树构建。这七种架构包括：x86（和 Athlon）、AMD64、Itanium 2、IBM 大型机（s390 和 s390x）以及 IBM 的 iSeries 和 pSeries PPC 系统。尽管上游内核在不同程度上支持这些架构中的每一种，但现实情况是，这些架构中的许多架构主要是在隔离状态下开发的。这不可避免地导致集成噩梦。
这个故事的另一个有趣的转折是红帽的内核开发团队实际上遍布全球。出于必要，这导致几乎所有交互都在网上进行。例如，我们很少举行团队会议，因为时区挑战会妨碍会议进行。有时这种在线交流会走向极端；使用 IRC 聊天会话与坐在隔壁办公桌的人交谈是很常见的。是的，我们的母亲是对的；我们是一群技术怪人。
正如内核开发永不停息一样，我们亲爱的合作伙伴和客户也不会停滞不前。在这个动态环境中，为数不多的不变因素之一是在整个版本开发过程中，不断涌入必须具备的危机功能添加。我们努力使其成为一种权衡，并剔除优先级较低的功能，以保持工作负载的合理性。然而，最终，它似乎永远不会达到如此完美的平衡。团队坚持不懈地应对所有这些需求的能力令人钦佩。
尽管红帽开发人员的效率很高，但一些突发功能总是不得不推迟到以后的版本或更新中。这些情况给我们的合作伙伴经理带来了无尽的创伤，他们不得不成为坏消息的传递者。我们的合作伙伴不太可能听说过“不要射杀信使”这句话。有一次，我们离发布还有两个小时，装货码头到货了。这是一台我们需要的新计算机平台，以便能够开发和测试对它的支持。合作伙伴难以置信我们无法满足他们的要求。
在整个开发过程中执行几个不同级别的测试。这一切都始于开发人员执行单元测试。这包括手动、动手测试以及开发自动化测试程序。随着新问题的解决，自动化测试集的规模也在不断扩大。然后，这些自动化测试程序被纳入由 QA 部门管理的测试网格中。除了内部编写的单元测试外，我们的测试网格还包括广泛的回归测试。示例包括 POSIX、LSB 合规性、LTP、crashme、gcc 套件和我们的合作伙伴提供的极其刁钻的测试。还使用诸如 cerberus、lmbench、bonnie、spec 和其他微基准测试等测试对一系列系统功能执行压力测试，仅举几例。这些自动化测试每晚运行，以便快速检测到回归。这对于隔离有问题的代码至关重要。相比之下，如果我们等到每月执行基准测试，那么识别罪魁祸首将更加困难。
在每晚测试的基础上，运行频率较低但更耗时的测试场景。示例包括使用我们在许多不同语言中支持的各种配置选项进行的安装测试。动手测试完善了内部 QA 覆盖范围。要公正地介绍勤奋的 QA 团队完成的惊人测试范围，远远超出了单篇文章的范围。
在内核通过内部单元测试和 QA 审查后，我们会将它们提供给我们的开发合作伙伴。这大大扩展了覆盖范围，将其他公司的外部 QA 和开发团队也包括在内。我们的合作伙伴将测试重点放在他们的硬件平台上以及他们的企业客户要求的典型服务器功能上。
最后一层测试包括外部 beta 测试人员。这些 beta 测试人员包括知名客户，以及 Linux 社区中许多响应我们的公开邀请以帮助进行测试的人员。
所有这些不同测试活动的结合产生了一个极其稳定且经过良好测试的产品。它还指出了开源模型的巨大价值。正是来自许多不同公司和敬业人士的测试资源的结合，才能够很好地扩展，超越了单个公司可以调动以应对无限测试矩阵的资源。
图 3 由 Nick Carr 创作，总结了从需求收集、开发和测试到最终产品化的开发模型。
图 3. 从需求收集到发布的开发过程
最终，红帽企业 Linux v. 3 发行版确实在 2003 年 10 月中旬按计划发布了。在一家主要的 IHV 的大型操作系统工程团队工作多年后，我接触过专有操作系统开发模型和开源开发模型。企业 Linux v. 3 发布的成功结果清楚地证明了协作开源开发的强大力量。功能数量、快速开发时间和参与者的素质（包括内部和外部）都非常出色，是对 Linux 社区的有力证明。
当版本发布时，我们都为自己为如此伟大的成就做出了贡献而感到自豪。但庆祝的时间窗口确实很短。企业 Linux v. 3 一完成，似乎我们就已经晚于企业 Linux v. 4 的开发了。这让我想起了那句话，“祝贺你赢得了这场战斗，这让你有幸回来并继续战斗。” 我得走了，还有更多的战斗要打。
Tim Burke 是红帽公司服务器开发总监。该团队负责内核和红帽企业 Linux 中包含的核心应用程序集。在成为经理之前，Tim 曾通过开发 Linux 高可用集群解决方案和 UNIX 内核技术谋生。
