与Thomas Gleixner对谈实时Linux内核补丁集

Linux 基金会编辑总监 Jason Perlow（JP）采访了 Linux 基金会研究员、Linutronix GmbH 首席技术官、PREEMPT_RT[1]实时内核补丁集项目负责人 Thomas Gleixner（TG）。

JP：Thomas 你好！很高兴今天早上能请到你，虽然对你来说，德国已经是下午了。关于今天的主题，内核的实时补丁集 PREEMPT_RT 是一个很吸引人的项目，因为它有一些非常重要的用例，而使用基于 Linux 系统的大多数人可能没有意识到。首先，你能告诉我“实时”是什么意思吗？

TG：在操作系统上下文中的实（Real-Time）是指操作系统提供了保证相关的实时任务在指定时间内处理事件的机制。实时常常与“非常快”相混淆。已故的 Doug Niehaus 教授这样解释：“实时不是尽可能快的；它是和规定的一样快。”

指定的时间约束依赖于应用程序。水处理厂的控制回路可以有相对较大的时间限制，以秒甚至分钟为单位，而机器人控制回路的时间限制在微秒范围内。但是对于这两种情况，错过了必须完成计算的最后期限都可能导致故障。对于某些应用程序场景，错过最后期限可能会产生致命的后果。

在严格意义上的实时，由操作系统提供的保证必须是可验证的，例如，通过数学证明最坏情况下的执行时间。在一些应用领域，特别是与功能安全相关的领域（航空航天、医疗、自动化、汽车等），这是一项强制性要求。但是对于其他场景或有提供安全需求的独立机制的场景，正确性的证明可以更轻松一些。但即使在更宽松的情况下，实时系统的故障也会造成实质性的损害，这显然是要避免的。

JP：这个项目背后的历史是什么？它是怎么开始的？

TG：Real-Time Linux 的历史远远超出了实际的 PREEMPT_RT 项目。

Linux 很早就成为了研究工具。实时研究人员着手将 Linux 转变为实时操作系统，并采用了不同的方法，或多或少都取得了成功。尽管如此，他们中没有人认真尝试过一个完全整合的、或许可以提交到上游的变种。在 2004 年，各方开始了一项不协调的努力，将一些关键技术引入 Linux 内核，他们希望在 Linux 内核上构建适当的实时支持。没有一个是完整的，并且缺少一个整体的概念。

为 RedHat 工作的 Ingo Molnar 开始捡起碎片，将它们重新组合并收集成一个补丁系列，为实时抢占补丁集 PREEMPT_RT 奠定基础。当时，我与已故的 Doug Niehaus 博士[2]合作，将我们现有的一个基于 2.4 Linux 内核的解决方案移植到 2.6 内核。我们的工作既有矛盾又有互补，所以我很快就和 Ingo 合作了，让它变得有用。Steven Rostedt 等人从其他 Linux Real-Time 研究工作中带来了一些想法和经验。有了一个由感兴趣的开发人员组成的松散的快速团队，我们能够在很短的时间内开发一个可用的实时解决方案，该解决方案完全集成到 Linux 内核中。这与可维护和生产就绪的解决方案相去甚远。尽管如此，我们已经打下了基础，并证明了使 Linux 内核具有实时性的概念是可行的。从一开始就有将其完全集成到主线 Linux 内核中的想法和意图。

JP：为什么现在它仍然是一个独立于主线内核的项目？

TG：为了将实时补丁集成到 Linux 内核中，必须首先做大量的准备工作、重组和巩固主线代码库。虽然由于其隔离性，许多从实时工作中出现的部分很快就进入了主线内核，但改变 Linux 内核基本行为的更具侵入性的更改需要（并且仍然需要）大量的润饰和仔细的集成工作。

当然，这必须与所有其他正在进行的工作协调，以便在从微型嵌入式系统到超级计算机的不同用例中采用 Linux 内核。

这也需要仔细设计集成，这样它就不会妨碍其他利益，也不会对进一步开发 Linux 内核造成障碍，这是社区，特别是 Linus Torvalds 非常关心的事情。

只要这些剩余的补丁不在主线内核中，这就不是问题，因为它不会给主线内核带来任何负担或限制。责任在实时项目上，但在另一方面，在这个上下文中，没有任何限制可以走上游内核永远不能接受的捷径。

实时补丁从根本上不同于位于源代码树某个角落的设备驱动程序。设备驱动程序在未被维护时不会造成任何更大的损坏，当它达到最终的位腐烂状态时，可以很容易地删除它。相反，PREEMPT_RT 核心技术位于 Linux 内核的核心。长期的可维护性是关键，因为这方面的任何问题都会影响到整个 Linux 用户世界。相比之下，一个位腐蚀的驱动程序只会影响到那些依赖于它的设备的少数人。

JP：传统上，当我想到 RTOS 时，我想到的是基于封闭系统的遗留解决方案。为什么我们有一个开源的替代品是必要的？

TG：实时操作系统的领域非常广泛，而且在很多情况下非常专门。正如我在“什么是实时”的问题上提到的，某些应用程序场景需要完全验证的 RTOS，通常根据特定于应用程序领域的标准和法规。除此之外，许多 RTOS 被限制在适合目标应用程序领域的特定类别的 CPU 设备中。其中许多都提供了需要特殊工具和专业知识的专用应用程序编程接口。

Real-Time Linux 项目从来没有把这些狭窄和专门的应用程序领域作为目标。它一直是 99%用例的解决方案，并且能够充分利用 Linux 内核和更广泛的 FOSS 生态系统的灵活性和可伸缩性，以便能够一致地处理具有混合临界工作负载的集成解决方案。

在支持实时的 Linux 内核上开发实时应用程序与在 Linux 上开发非实时应用程序没有太大的区别，除了要仔细选择可以利用的系统接口和应该避免的编程模式之外，但这对于一般独立于 RTOS 的实时应用程序编程来说是正确的。

重要的区别在于，工具和概念都是相同的，集成到更大的 FOSS 生态系统中并加以利用是免费的。

PREEMPT_RT 的缺点是它不能被完全验证，这将它排除在特定的应用程序空间之外，但目前正在进行一些工作，例如 LF ELISA 项目，以填补这一空白。其背后的原因是，大型多处理器系统已成为一种商品，并且在各种应用空间（例如，辅助/自动驾驶或机器人技术）中需要更复杂的实时系统，这需要比大多数经过验证的专业 RTOS 可以提供更灵活和可扩展的 RTOS 方法。

这是一条很长的路。尽管如此，现在仍然有一些解决方案利用外部机制来实现某些应用程序领域的安全需求，同时利用支持实时的 Linux 内核的全部潜力以及更广泛的 FOSS 生态系统的广泛产品。

JP：有哪些产品和系统使用人们经常依赖的实时补丁集的例子？

TG：现在到处都是。工业自动化、控制系统、机器人、医疗设备、专业音频、汽车、火箭和电信，这只是几个突出的领域。

JP：目前开发实时 Linux 内核补丁集的系统和工具集的主要参与者是谁？

TG：把它们都列出来就等于在背诵行业中的“名人录”。在发行端，有来自 RedHat、SUSE、Mentor 和 Wind River 等公司的产品，它们将 RT 交付给不同应用领域的广泛客户。在产品方面，有 Concurrent、National Instruments、Boston Dynamics、SpaceX 和 Tesla 等公司。

RedHat 和 National Instruments 也是 LF 协作实时项目的成员。

JP：为 Linux 开发实时子系统或专门的内核有什么挑战？它与内核的其他项目运行有什么不同吗？

TG：没有什么不同；同样的规则适用。补丁必须发布、审查和讨论。然后反馈被合并。循环开始，直到每个人都同意解决方案，补丁被合并到相关的子系统树中，最后在主线内核中结束。

但正如我之前解释的那样，它需要大量的注意和努力，通常还需要大量的额外工作来重构现有代码，以便集成特定的补丁。结果是提供了期望的功能，但同时不是以其他利益的方式，或者，理想情况下，为每个人提供好处。

该技术的复杂性涉及到广泛的核心内核代码，这显然是一个挑战，特别是结合主线内核的快速变化率。即使在相关的核心基础设施级别发生更大的变化，也不会过多地影响正在进行的开发和集成工作，比如驱动程序或文件系统。但是，对核心基础架构的任何更改都可能破坏对实时部分的仔细考虑的集成，并使我们暂时回到绘图板上。

JP：哪些公司一直在支持 PREEMPT_RT Linux 内核补丁的上游工作？

TG：在过去的 5 年里，它得到了 LF 实时 Linux 项目成员的支持，目前包括 ARM、BMW、CIP、ELISA、Intel、National Instruments、OSADL、RedHat 和 Texas Instruments。CIP、ELISA 和 OSADL 是独立的项目或组织，其成员公司遍布整个行业。以前的支持者包括谷歌、IBM 和 NXP。

我个人、我的团队和更广泛的 Linux 实时社区非常感谢这些成员提供的支持。

然而，就像在关键基础设施中大量使用的其他关键开源项目一样，资金一直是一个困难的挑战，现在仍然是。即使维持这种低水平的基础功能所需的资金相对较少，这些项目也很难找到足够的赞助商，而且往往缺乏长期的承诺。

这种为此类项目提供资金的方法让我想起了在欧洲流行的 Mikado 游戏，即第一个拿起棍子并扰乱游戏堆的玩家往往就是输家。

这让我很困惑，特别是许多公司依靠这些技术开发关键产品，似乎把可用性和可持续性视为理所当然，直到项目失败，或者人们因为缺乏资金而停止工作。这些公司应该认真考虑支持 Real-Time 项目的资金。

这很像层层叠游戏，每个人都拿出尽可能多的棋子，直到它崩溃为止。我们不能继续索取；我们必须回报这些社区，他们为公司严重依赖的技术付出了艰苦的努力。

很久以前，我就放弃了对这一现象的理解，尤其是当我看到大量资金投入到当今过度炒作的技术上时。尽管对该行业的很大一部分来说至关重要，但低水平的基础设施缺乏吸引关注和成为头条新闻的流行词魅力——但它仍然需要支持。

JP：历史问题之一是，Real-Time 并没有一个与之相关的社区；过去五年发生了什么变化？

TG：这里有一个活跃的用户社区，其中很多活动都来自于 LF 项目成员。就开发本身而言，我们正在慢慢地吸引更多的人来理解 PREEMPT_RT 的复杂之处，以及从其他角度来看待它的人，比如分析和工具。有些领域可以改进，比如文档，但总有一些地方可以改进。

JP：一旦上游接受了这些补丁，Real-Time Stable 团队会做什么？

TG：稳定团队目前正在监督受支持的主线稳定版本的 RT 变体。一旦所有东西都集成了，一旦旧版本达到 EOL，这种情况就会在某种程度上消失。但是他们的专业知识仍然需要在主线和支持主线的稳定内核中保持实时特性。

JP：那么，一旦上游操作完成，会发生什么呢？

TG：一旦完成上游操作，就必须努力为当前在实时启用的内核上禁用的特定 Linux 功能启用 RT 支持。此外，在相当长的一段时间内，当内核中其他东西发生变化时，将会有附带影响，并且必须支持那些遇到 RT 限制的内核开发人员，而这些限制是他们以前没有考虑过的。

后者是这一努力的关键。因为需要有一个明确的长期承诺，让那些对事情和概念非常熟悉的人不会在主线完成后就消失。我们不能让其他人在绝望中绞尽脑汁地思考这个问题；在一个如此重要的体系中，不可能存在机构知识的流失。

缺乏这样的承诺将成为最后一步的阻碍，因为我们现在所处的位置是，显著的变化只集中在实时方面，而不是欢迎清理、改进和具有普遍价值的特性。反过来，这又回到了之前关于资金和行业支持的问题——因为这最后一步需要使用实时内核的公司几年的承诺。

不会缺少需要努力的东西。它不会像当前的努力那样多，但由于内核永远不会停止改变，这在长期以来将很有趣。

JP：Thomas，谢谢你今天上午抽出时间。这是一个很有启发性的讨论。

要了解 Linux 实时内核补丁，请访问 Linux 基金会的 PREEMPT_RT wiki 或发送电子邮件到 real-time-membership@linuxfoundation.org

参考资料

[1]

PREEMPT_RT: https://wiki.linuxfoundation.org/realtime/start

[2]

已故的 Doug Niehaus 博士: https://lwn.net/Articles/514182/?fbclid=IwAR1mhNcOVlNdQ_QmwOhC1vG3vHzxsXRwa_g4GTo62u1sHbjOZBPPviT5bxc