LWN：kernel defconfig是为谁准备的？

关注了就能看到更多这么棒的文章哦～

Who are kernel defconfigs for?

By Jonathan Corbet
June 24, 2025
Gemini flash translation
https://lwn.net/Articles/1026337/

在内核上工作可能是一项具有挑战性的任务，但对许多人来说，配置内核构建（kernel build）可能是入门最大的障碍。内核有数千个配置选项（configuration options）；其中许多选项如果设置不正确，将导致内核无法在目标系统上运行。帮助用户解决复杂配置问题的关键在于提供合理的默认配置，但在内核社区（kernel community）中，目前对于这些默认配置应该是什么，还没有形成共识。

内核的配置选项控制着内核如何构建的诸多方面。例如，每个设备驱动（device driver）都有一个配置选项，通常这些驱动所属的子系统（subsystems）也有。如果未能启用所需的驱动，将导致内核无法正常工作；而启用所有驱动则会导致构建过程（build process）耗时过长，最终生成一个庞大的内核。配置选项还控制着许多功能和系统调用（system calls）的可用性、安全缓解措施（security mitigations）和策略的应用、许多调试功能、子架构支持（subarchitecture support）等。许多选项相互依赖或冲突。

要理清这个复杂的配置选项迷宫并非易事；内核提供了一些配置编辑工具，但它们能提供的帮助有限。有一些 `=make=` 命令选项可以启用或禁用所有配置选项；这些选项对于构建测试（build testing）很有用，但很少用于创建实际运行的内核。通过 `=make localmodconfig=` 命令可以获得更多帮助，它会检查当前运行内核中已加载的模块，然后生成一个仅构建这些模块的配置。Eric Raymond 曾 试图将配置过程变成一个冒险游戏，但这对于驯服其中遇到的“怪物”作用甚微。

最终，许多人只是从一个已知可用的配置（known-working configuration）（也许来自他们的发行版）开始，根据需要进行调整，然后尽量不再考虑它，只要生成的内核还能工作就行。Linus Torvalds 曾多次表示，配置系统（configuration system）是一个问题：

各位，我之前说过，现在看来我需要再说一遍：内核配置（kernel config）可能是构建本地内核最糟糕的部分，也是阻碍人们实际构建自己内核的最大障碍。

而人们构建自己的内核是成为一名内核开发者（kernel developer）的第一步。

还有另一个操作，即 `=make defconfig=` 命令，它会创建一个架构特定的配置，旨在成为一个良好的起点，提供一套合理的默认配置，从而创建一个可工作的内核。x86 架构（x86）的维护者之一 Ingo Molnar 最近得出结论，x86 默认配置（x86 default configuration）已经偏离了这些目标；他发布了 一系列补丁（patch series），旨在使该配置现代化：

历史上，x86 默认配置（defconfigs）旨在成为发行版内核的类似物（distro kernel work-alikes），拥有更少的驱动和显著更短的构建时间（build time）。我们定期要求贡献者（contributors）在 x86 默认配置上测试他们的更改，并且我们经常也会分析此类内核上的代码生成（code generation）。

实际上，在过去几年里，这个目标已经与现代 Linux 发行版（Linux distributions）所做的实际工作有所偏离，本系列补丁旨在纠正这种偏离。

这个系列对现有默认配置做出了不少更改：

• 虚拟化（Virtualization）方面的改动包括为 Xen、Jailhouse、ACRN 和 Hyper-V 等虚拟机监控器（hypervisors）启用客户机支持（guest support），以及英特尔的 TDX 机密计算机制（Intel's TDX confidential-computing mechanism）。运行 KVM 主机（KVM host）的支持也 被启用。

• 当前的 x86 默认配置不包含 BPF 机制（BPF）；Molnar 的补丁集 将其开启，包括 BPF 安全模块（BPF security module）。

• 它 启用了许多内存管理选项（memory-management options），包括内存热插拔（memory hotplugging）、内核同页合并（kernel samepage merging，KSM）、透明大页（transparent huge pages）、userfaultfd 机制（userfaultfd）、内存控制组（memory control groups）以及 多代 LRU（multi-generational LRU）。

• 在 核心内核（core-kernel）方面，核心调度（core scheduling）、NUMA 均衡（NUMA balancing）、命名空间（namespaces）、压力停顿信息（pressure-stall information）和 BSD 进程记账（BSD process accounting）等功能均已启用。

• 许多 调试选项（debugging options）也已启用，包括 kgdb 调试器（kgdb）、UBSAN 工具（UBSAN）、函数性能分析（function profiling）等等。

这个系列总体上收到的评论不多，但 Peter Zijlstra 抱怨道，他认为内存管理方面的改动（特别是启用 KSM）是“巨大的安全失败”。Torvalds 反过来 强烈要求 Molnar 停止这项工作，称默认配置应该适用于“普通人”。他表示，对云服务提供商（cloud providers）（例如虚拟化子系统）有用的选项不应该被启用。在他看来，所有发行版维护者（distributors）都启用了某个特定选项，这也不是在默认配置中启用该选项的理由。Torvalds 似乎希望配置系统变得更容易操作，但显然这不是他希望完成的方式。

Molnar 回应并详细阐述了他进行这些更改的理由，称他希望为那些向内核贡献补丁（contribute patches）的人提供更简单的内核配置（kernel configuration）。这个群体包括为云服务提供商工作的开发者，而 Torvalds 并不认为他们是“普通人”。Molnar 问道：

为什么不让默认配置（defconfig）在我们更广泛的实际贡献者的测试环境中开箱即用呢，只要构建成本（build cost）不是太高？

他补充说，内核开发者（kernel developers）倾向于使用与发行版维护者发布的配置显著不同的配置进行工作（和测试），这可能会导致当发行版维护者启用了开发者所避免的选项时，在下游（downstream）出现问题。

尽管阐述了理由，但 Molnar 似乎不准备争论。他已经从补丁系列中移除了大部分更改，并表示：

这些提交不会再回来了。显然，我使用发行版内核配置（distro kernel configs）的最小公分母（lowest common denominator）的方法不被欣赏，我根本不想与这种阻力（pushback）作斗争。

Torvalds 没有回应，也没有其他人加入讨论，因此对话就此结束。至少目前，x86 默认配置与发行版维护者使用的配置将显著不同，并且将缺乏许多人可能希望在其构建的内核（built kernels）中拥有的功能。这种情况可能会持续一段时间。内核构建系统（kernel's build system）是很少有开发者选择涉足的领域；它由一位开发者维护（并且可能只有他真正理解）。如果连一组基本默认配置都无法达成共识，那么似乎不太可能期望有更显著的改进。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～