LWN：用 LLM 帮助内核开发！

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

Supporting kernel development with large language models

By Jonathan Corbet
June 26, 2025
OSSNA
Gemini flash translation
https://lwn.net/Articles/1026558/

内核开发和机器学习看起来是截然不同的领域；目前，还没有关于凭直觉编程（vibe-coding）写出新的内存管理算法的故事出现。不过，机器学习（尤其是大型语言模型 —— LLM）很可能会在内核项目的边缘发挥作用。在 2025 年北美开源峰会上，Sasha Levin 展示了他如何利用 LLM 来改进内核的一些工作。

他首先指出，LLM 本质上只是一个参数众多的模式匹配引擎；它是一个庞大的状态机。然而，与内核中常见的那种状态机不同，LLM 执行状态转换的方式是概率性的，而非确定性的。给定一系列词语，LLM 会生成序列中下一个可能的词语。例如，如果给定“Linux 内核是用……编写的”，LLM 几乎肯定会回答“C”。但它回答“Rust”或“Python”的概率则要低得多。

LLM 使用一个“上下文窗口”（context window），这是用户提供的文本，模型在回答问题时可以记住这些文本。像 Claude 这样的系统拥有约 20 万个令牌（token）的上下文窗口，这足以容纳整个内核子系统。

Levin 认为 LLM 不会取代人类在内核开发等任务中的作用。相反，LLM 应该被视为下一代高级编译器。曾几何时，开发者使用汇编语言工作；后来高级语言出现了。有些人嘲笑这项新技术，说“真正的开发者”都是自己做寄存器分配的。但随着时间的推移，开发者采用了更好的编程语言，效率也得到了提高。LLM 只是朝着这个方向迈出的又一步；它不是一个完美的工具，但足以提高生产力。

LLM 生成的代码在内核中的应用

举例来说，他提到了 一个归功于他的补丁，该补丁已合并到 6.15 版本中。这个补丁完全由 LLM 编写，包括更改日志（changelog）。Levin 对其进行了审查和测试，但并未亲自编写代码。他说，这个修复很好地说明了 LLM 的优势；它们擅长小型、定义明确的任务，但不能要求它们编写新的设备驱动程序。LLM 还有助于编写提交信息（commit message），这通常比编写补丁本身更难，特别是对于母语不是英语的开发者而言。

他指出了补丁本身的一些内容，摘录如下：

-/* must be a power of 2 */-#defineEVENT_HASHSIZE128+/* 2^7 = 128 */+#defineEVENT_HASH_BITS7

从一个哈希接口（Hash API）切换到另一个接口时，需要将大小指定为 2 的幂而不是直接的位数；LLM 考虑到了这一点并进行了相应的修改。它还在补丁的后续部分意识到不需要进行掩码操作（masking operation），因此将其去除了。他说，LLM 生成的代码既正确又高效。

另一个例子是已合并到 6.16 版本的 git-resolve 脚本。这个脚本源于 2024 年底关于模糊提交 ID（commit ID）的讨论，它能将模糊（甚至不正确）的 ID 解析为完整的提交。它同样是由 LLM 生成的。它不仅能正常工作，还包含了一整套自测试（self test），他（轻描淡写地）指出这在内核的 scripts 目录中的代码里是不常见的。他说，LLM 在被要求生成测试时，“不会给你一个不开心的表情”。该脚本包含文档（documentation）（在该目录中也很不常见），并且正在内核社区中日常使用。

接着，他介绍了“嵌入”（embeddings）的概念，这是一种在 LLM 内部表示文本的方式。它们可以被认为是编译器内部程序表示的等价物。嵌入将人类语言转换为可以进行数学处理的向量（vectors）。它们保留了文本的语义（semantic meaning），这意味着具有相似含义的短语会“编译”成相似的嵌入。反过来，这使得基于含义的搜索成为可能。在内核上下文中，嵌入可以帮助搜索与给定示例相似的提交或错误。

另一种有用的 LLM 技术是“检索增强生成”（RAG）。他说，LLM 在不知道问题答案时，不幸地倾向于凭空捏造；LLM 很少会承认自己不知道某事。这对于生成的代码来说“非常令人恼火”；例如，LLM 会凭空捏造不存在的内核函数。RAG 的作用是为 LLM 提供依据（ground），使其基于实际知识，让模型能够根据需要查找信息，就像人类使用文档一样。它还有助于用模型训练完成后才出现的知识来更新 LLM。

特别是在内核领域，RAG 可以为模型提供依据，并教会它内核特定的模式。它还增加了可解释性（explainability），模型可以引用具体的例子来解释其做出的决策。除其他功能外，RAG 允许模型连接到 Git 仓库（Git repository），使其能够访问内核的开发历史。

更新与 CVE

稳定版内核包含大量从主线（mainline）向后移植（backported）的补丁；例如，5.10 系列在初始 5.10 发布后，已合并了超过 31,000 个提交。维护这些稳定版更新需要每天审查大约 100 个补丁——每天，没有休息。其中，可能只有五到十个适合向后移植。这是一个繁琐且令人沮丧的过程，而且不可扩展（scale）；结果是，总是有重要的修复被漏掉。

“AUTOSEL”工具已经存在多年；它试图选择主线中应考虑向后移植的提交。最初的版本很原始；它只会查找更改日志中的特定关键词。将 AUTOSEL 切换到 LLM 会使其表现得像“另一个稳定版内核维护者”，只不过它是一个特殊的维护者，能记住所有曾做过的向后移植决策。它的工作原理是为历史中的每个提交创建一个嵌入，然后查找与可能解决同一类问题的新提交之间的相似之处。

他指出，AUTOSEL 并未取代稳定版维护者，但它确实缩小了他们必须考虑的提交范围。它能够快速处理数百个提交，捕获人类会遗漏的修复。它还在发送到邮件列表的每封电子邮件中解释其推理 (随机示例)，提议将补丁向后移植。他说，当被要求考虑一个特定提交时，AUTOSEL 也能推荐相似的提交供考虑。

人们会问 AUTOSEL 使用的是哪个 LLM；答案是“所有”。每个模型都有其自身的优缺点，因此 AUTOSEL 会询问多个模型，然后让它们各自对结论进行投票。如果足够多的模型投票支持向后移植，它就会被转交给人类进行考虑。

2024 年初，内核项目 承担了分配自身 CVE 编号的责任。支持这项工作的工具最初是一堆“临时性的 Bash 脚本（Bash hacks）”，很快就变得难以维护。因此，CVE 团队决定将它们转换为 Rust，因为“那是酷孩子们现在做的事”。唯一的问题是 CVE 团队成员都是内核开发者，他们对 Rust 并不那么精通。然而，LLM 精通 这门语言，能够快速重写这些脚本，并在此过程中添加了文档和测试。新脚本更易于维护，效率也大大提高。

CVE 流程本身类似于向后移植的挑战；必须审查提交以判断其安全相关性，这又是另一个繁琐的任务。很难找到具备所需专业知识的人来做这项工作；拥有所需技能的人可以轻易找到更有价值的工作。因此，一个纯粹基于人类的流程会滞后，遗漏重要的漏洞，同时偶尔会标记出实际上不是漏洞的错误。

换句话说，这是机器的另一个工作。CVE 选择可以共享 AUTOSEL 使用的大部分基础设施，但这次要求 LLM 寻找那些与之前漏洞修复有某种相似之处的提交。

他总结说，通过使用 LLM，内核社区现在拥有一个系统，可以利用多个模型，直接访问 Git 仓库，并利用历史数据来回答关于内核补丁的各种问题。他提供了 AUTOSEL 和 提交分类器（commit classifier） 的网址。

Tim Bird 问是否存在人类过于信任 LLM 输出的风险，从而导致错误潜入。Levin 同意 LLM 可能会出错，但他说人类也会出错，而且经常出错。另一位参与者询问 LLM 生成代码的许可（licensing）问题；Levin 说他还没有真正考虑过这个问题，并认为如果 LLM 生成了代码，他可以自由使用。

最后一个问题是，这个基础设施是否可以用于在合并之前检查补丁，以期更早地发现错误。这是 Levin 过去探索过的领域，但目前并不是重点。他同意 LLM 可以做这项工作，但这将是一项巨大的任务，而且 LLM 目前的使用成本仍然太高。他说，也许将来，当价格下降时，这种分析将成为可能。

[感谢 Linux 基金会对我们参加本次活动的支持。]

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

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

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