与往常一样，Linux 内核社区一直忙于推动 Linux 主线达到另一个终点，并将稳定版和扩展版发布到下一个修订版本，以修复安全漏洞和错误。这是一个稳定且有条不紊的演进过程，非常有趣。以下是我对 2013 年 6 月 Linux 内核世界发生的事件的看法。

主线发布（Linus 树）新闻

Linus Torvalds 发布了 Linux 3.10。您可以在他的发布公告中阅读 Linus Torvalds 对此版本的评价：http://lkml.indiana.edu/hypermail/linux/kernel/1306.3/04336.html

此版本中的两个显着功能是改进的 SSD 缓存和更好的 Radeon 显卡驱动程序电源管理。

稳定版发布新闻

截至撰写本文时，

• 当前稳定版是 3.9.8。（3.9.9-rc 已发布用于测试
• 长期稳定版是 3.0.84（3.0.85-rc 已发布用于测试）、3.2.48 和 3.4.51（3.4.52-rc 已发布用于测试）。
• Canonical 继续其扩展稳定维护。Canonical 通过遵循 Linux 开发流程，使内核社区参与到扩展版本的维护中。因此，这些版本受益于内核开发人员贡献的补丁以及对候选版本的审查和测试。在我看来，这使 Canonical 与其他发行版区分开来。
  • 扩展稳定版是 3.8.13.4。Canonical 的 Kamal Mostafa 维护 3.8.13.y 版本，用于 Ubuntu 13.04 的错误修复和安全更新。
  • 扩展稳定版是 3.5.7.15。Canonical 的 Luis Henriques 维护 3.5.7.y 版本，用于 Ubuntu 12.10 的错误修复和安全更新。
• Linux RT
  • 3.6.11.3-rt36，由 Steven Rostedt 维护
  • 3.8.13-rt12，由 Sebastian Andrzej Siewior 维护。

请注意，稳定版的错误修复会通过 Linus 的主线。补丁应先提交到 Linus 的主线，然后稳定版维护人员才能将其接受到稳定版中。补丁更改日志应包含主线 git 提交 ID。

节能调度设计

Ingo Molnar（Red Hat，x86 维护人员）、Morten Rasmussen（ARM，电源管理）、Priti Murthy（IBM，调度程序）、Rafael Wysocki（Intel，Linux PM 和 Linux ACPI 维护人员）和 Arjan van de Ven 讨论了拟议的电源感知或节能调度程序设计，以及将其集成到内核中的最佳方法。

电源管理和平衡性能与电源效率的能力非常重要且复杂。这不仅仅关乎调度程序或 CPU。它还涉及转换到低功耗状态的 I/O 设备，以及在需要时将其恢复到完全活动状态的成本。这些转换中存在延迟。与往常一样，Linux 开发人员达成共识，以解决诸如此类的复杂问题，并提出实现目标的路径，朝着目标迈出小步。这是工作中该过程的另一个例子。

节能调度程序工作已经活跃了几个月。已经发布和讨论了几个 RFC 补丁。IBM 在 x86 领域和 ARM 在 ARM 领域非常积极地追求这项工作。前提是，如果调度程序可以将任务打包到少数几个核心上并保持这些核心的充分利用，并且在调度目标是节省功耗而不是性能时，将其他核心转换为低功耗状态。换句话说，调度程序可以将任务整合到少数几个核心上，并将其他核心转换为低功耗状态，以提高电源效率，而不是保持所有核心都处于活动状态。

说起来容易做起来难。调度程序处于更高的级别，不会是就 CPU 转换为空闲状态和决定它们应该以理想频率运行做出决策的最佳判断者。这些决策最好留给平台驱动程序，因为它们具有平台和架构的特定知识，因为它们很复杂且非常特定于硬件。换句话说，经过调整以在 x86 平台上良好运行的电源感知调度程序在 ARM 平台上可能无法很好地工作，甚至可能惨败。

调度程序必须以满足性能和电源目标的方式完成负载平衡以及电源平衡，并在所有平台上都做得很好。通用调度程序不必控制和驱动平台上的低功耗状态决策。但是，节能调度程序的目标是设置更高级别的抽象策略，这些策略将在所有平台上都有效。经过长时间富有成效的讨论，达成共识，以下是总结

• 一个新的内核配置选项 CONFIG_SCHED_POWER，用于启用/禁用电源调度程序功能。当 CONFIG_SCHED_POWER 禁用时，电源调度程序完全不活动，当 CONFIG_SCHED_POWER 启用时，电源调度程序完全活动。重要的目标是在不中断和破坏当前调度程序的情况下发展电源调度程序功能。
• 在具有硬件和平台抽象的通用电源调度程序上工作，该调度程序将在大小核 ARM、x86 和其他平台上良好工作。避免特定于平台的电源策略，这可能会导致平台特定电源驱动程序中功能重复。

请查看 Linux 基金会网站，了解 2013 年 4 月在 Linux 协作峰会上就此主题所做的演示。这是 Jonathan Corbet 关于此主题的博客链接。
http://www.linux.com/news/featured-blogs/200-libby-clark/715486-boostin…

内核中允许递归例程吗？

递归通常使代码变得简单，但是存在与错误的非终止递归逻辑相关的风险。当递归例程失控并溢出有限的内核堆栈时，可能会覆盖随机内核内存。这将导致磁盘和数据损坏，具体取决于所述内存位置的内容。故事的寓意以及我对最近关于 IOMMU 补丁的 lkml 讨论的看法是

“在绝对必要时使用递归，并确保它没有错误并保持这种状态。”

dmesg 错误报告机制的替代方案

几个内核模块使用 dmesg 来报告错误和其他信息。它是一个简单易用的机制，并且始终存在，无需额外工作。但是，它不能很好地扩展，并且消息可能难以过滤和扫描。有一些更适合报告的替代方案，这些方案是可扩展的。Tracepoint 和事件就是这样一种基础设施，模块正在使用这种方法来处理新事件，并且也在各个模块级别进行将基于 dmesg 的报告转换为使用 tracepoint。对于某些平台模块，例如 ACPI 和 EFI 等，EDAC 框架可能比单独使用 tracepoint 更好。从内核首次错误处理和报告的卑微开端开始，EDAC 已经发展到包括平台上的固件优先错误处理，这些平台通过 APEI 支持固件中的错误检测和纠正。当错误检测和纠正可以跨越固件和内核时，EDAC 是作为报告框架的更好选择。

总而言之，对于不经意的观察者来说，Linux 开发过程可能显得混乱和临时。但是，它是有条不紊和有组织的。随着 3.10 版本的发布，现在是开始集成 3.11 内容的时候了，从 rc-1 到 rc-? 并行继续进行 3.12 的开发工作。3.12 版本可能包括第一个版本的电源感知调度程序，并且更多模块可能会切换到使用 trace-point 基础设施来处理事件和错误，并且演进和创新仍在继续。

玉米图片，通过 Shutterstock.com。