LLM辅助Linux驱动开发：drivers/staging的准入策略与审查实践

最近在整理内核开发相关笔记时，重新看到了一个很有意思的议题：LLM policy for drivers/staging/ going forward。很多人第一次看到这个标题会下意识以为是“怎么用大模型去写 Linux 驱动”，但如果结合内核社区最近的讨论来读，会发现它真正想表达的是：面向 drivers 和 staging 这两个内核关键目录，未来如何制定大语言模型辅助编码的接入策略。

这个议题对内核开发者、嵌入式工程师、以及正在做 LLM 工程化落地的人来说都值得关注。原因很简单：LLM 生成代码已经不是能不能用的问题，而是如何用、谁来负责、怎么保证内核质量与安全的问题。本文会把背后的机制讲清楚，同时给出可落地的驱动开发工作流、代码检查命令、补丁自检方法和工程建议，尽量做到新人能看懂概念，老手能直接拿去参考。

1. 背景与核心概念

1.1 先理解 drivers/staging 是什么

在 Linux 内核源码目录中，drivers/是存放设备驱动代码的主目录，按设备类型分成net、usb、gpio、i2c、dma等子目录。比如网卡驱动可能在drivers/net/ethernet/，USB 转串口驱动可能在drivers/usb/serial/。

而drivers/staging/是一个比较特殊的目录，它专门用来存放还没有完全达到内核主线质量要求、但又有合入价值的驱动代码。这些驱动代码可能来自厂商开源、可能来自社区实验项目，也可能是一些旧驱动需要重构。把它们放进 staging 目录，等于给它们一个“观察期”：代码可以编进内核，但不会直接进入正式分类目录。

每个 staging 驱动通常带一个TODO文件，里面写清楚距离正式合入drivers/还差哪些工作，比如：

• 删除重复代码
• 修复明显的 bug
• 遵循 kernel coding style
• 补齐设备树绑定文档
• 替换被废弃的内核 API

这种做法最大的好处是保证主目录的代码质量，同时避免大量驱动没地方放。缺点是 staging 中的代码质量参差不齐，很多驱动常年无人清理。

1.2 LLM 辅助内核开发的现状

大语言模型在软件领域的应用已经非常常见，日常写业务代码、分析日志、生成测试用例、解释复杂函数，都有现成工具。内核开发领域同样开始出现 LLM 的身影，主要场景包括：

• 代码解释与知识检索：通过 RAG 方式把内核源码、邮件列表、文档做成知识库，帮助新人快速理解某个驱动的调用链。
• 补丁生成：让 LLM 根据 TODO 文件生成重构思路，或者生成修复代码片段。
• 静态审查辅助：让 LLM 作为“第二双眼睛”辅助 review，检查空指针、内存泄漏、并发问题。
• 提交说明生成：根据变更内容生成规范的 commit message。

这些场景听起来很高效，但内核开发有极强的约束：代码要符合编码规范、要能被多个架构编译、要尽量不引入新问题。任何一个被合并的补丁，署名作者和 Reviewer 都需要对质量负责。由此就引出了“LLM policy going forward”这个核心问题——未来要不要管、怎么管、由谁管。

1.3 “LLM policy”到底在讨论什么

翻译成直白的中文，这个讨论大致聚焦在三个层面：

1. 提交政策：开发者使用 LLM 生成的代码提交到内核邮件列表时，是否需要主动披露？社区是否接受纯 AI 生成的驱动？
2. 质量政策：LLM 生成的代码是否必须通过额外的静态检查、构建测试、维护者人工 review？
3. 维护责任：当一块驱动主要由 LLM 生成时，后续如果出现漏洞或兼容性问题，责任边界在哪？

从内核社区现有的公开讨论方向来看，目前并没有一个“一刀切”的硬性规则，整体更倾向保守接受：把 LLM 当作工具辅助开发是可以的，但最终提交的代码、文档、测试结果，仍然由人工开发者负责。涉及驱动安全、固件加载、硬件初始化的代码，人工审查的权重只会更高。

2. 为什么 staging 目录对 LLM 政策如此敏感

2.1 staging 是驱动进入内核的第一站

很多新驱动进入内核的路线是：厂商最初发布 -> 社区 patch -> staging 观察 -> 逐步清理 -> 正式合入drivers/对应子目录。这意味着 staging 是“准入门槛”的试验场，对代码质量的容忍度稍微高一些，但也不是什么都收。

LLM 生成代码最典型的应用场景，恰好就是处理 staging 里那些重复、模式化、机械化的代码清理任务。比如把foo指针判断改成统一风格，把printk改为dev_dbg，把不规范的注释统一成内核 doc 风格。这些任务重复度高、规则明确，很适合交给 LLM 做初稿，再由人确认。

但也正因为 staging 本身是“待改进”区域，如果 LLM 批量生成代码，可能产生大量“表面合规、实际有隐患”的补丁。比如把代码格式改对了，却破坏了原有的内存释放顺序；或者自动“修复”某个警告，实际却引入了空指针问题。所以业界对 LLM 进入 staging 的担忧，并不是“工具新”，而是“量的扩大会让审查质量难以保证”。

2.2 代码质量问题与社区信任

内核社区非常依赖 maintainer（维护者）的 review 质量。一个 patch 合入后，如果出现问题，维护者和作者都要承担风险。LLM 生成代码的模式，天然容易制造“看起来没问题”的补丁：

• 语法正确、风格符合规范；
• 能通过checkpatch.pl；
• 单看某个函数好像没问题；
• 但跨模块的并发、锁、中断上下文、缓存一致性等全局性问题，LLM 很难给出可靠判断。

所以，对 staging 目录而言，真正需要的不是“禁止 LLM”，而是建立一套适合 AI 辅助时代的审查强化流程。

2.3 从“LLM 生成补丁”到“LLM 驱动”的边界

现在的讨论有一个明显边界：LLM 生成一个 20 行的修复补丁，和一个 LLM 从零生成一个完整网卡驱动，风险完全不同。前者人工 review 成本低，社区接受度已经比较高；后者涉及硬件寄存器、DMA 描述符、电源管理、中断处理等各种细节，LLM 即使能生成框架，也大概率需要大量调试。

从工程角度看，更合理的策略是：

• 低风险、机械化的清理类补丁，可以接受 LLM 辅助；
• 高风险、涉及硬件协议栈和底层并发逻辑的驱动代码，必须由有经验的开发者主导，LLM 只承担解释、审查辅助等角色；
• 所有 LLM 参与生成的代码，都要提前说明，并在提交信息里交代背景。

3. LLM 辅助驱动开发的技术栈与工作流

这里我们先把“政策”放下，看看在实际开发中，一套合规且可落地的 LLM 辅助驱动开发工作流应该怎么设计。

3.1 通用 LLM 辅助开发基础设施

如果你负责一个驱动仓库，或者经常跟内核代码打交道，可以考虑搭建三类基础设施：

第一类是代码知识库。将内核源码、驱动源码、Documentation文档、邮件列表中的关键讨论切片后存入向量数据库，通过 RAG 接口让模型回答“某个函数在哪里定义”“某个驱动如何调用 DMA API”。llm wiki这类知识管理方案就是一个很常见的方向，它把零散的资料整理成可检索的卡片，再与模型工具连接。

第二类是工具体系。让 LLM 不只是输出文本，而是能调用真正的开发工具，比如执行git diff、跑make、运行checkpatch.pl、查看dmesg日志。这一步会涉及 LLM Agent 的编排：模型根据用户需求规划工具调用序列，然后逐步执行。社区里对这一块的讨论已经很多，比如通过 MCP 协议把开发工具接入客户端，让模型能访问构建结果。

第三类是人工审查沙箱。所有 LLM 生成的代码统一进入一个临时分支或 merge request，由 CI 自动跑编译、静态检查和基础运行测试，再交给维护者 review。不要让 LLM 直接把代码推送进主分支。

3.2 针对内核代码的关键配置思路

内核代码跟普通应用代码不同，LLM 提示词和上下文设计必须考虑几个点：

• 内核编码规范：让模型生成代码时优先参考Documentation/process/coding-style.rst，比如缩进建议用 Tab、单行长度限制、函数命名风格等。
• 内核版本差异：不同内核版本的 API 可能不同，要在 prompt 中明确告诉模型基于哪个版本分析，避免生成已废弃的接口。
• 驱动生效范围：驱动代码涉及硬件平台，需要提供足够上下文，比如设备树、寄存器手册摘要、数据手册片段。没有这些信息，模型大概率会“自由发挥”。

下面是一个简单的提示词模板，可以用在代码解释或初步分析场景：

你是一位 Linux 内核驱动维护者。请分析下面这段 drivers/staging 下的 C 代码，重点关注： 1. 是否存在明显的内存泄漏、空指针解引用或错误路径返回值问题； 2. 是否符合内核编码风格（Tab 缩进、函数命名、注释格式）； 3. 如果要移动到 drivers/ 主目录，还缺少哪些必要条件（文档、设备树绑定、TODO 清理项）。 输入代码： <粘贴代码片段> 输出格式： - 问题列表（按严重程度排序） - 每个问题的修改建议 - 风险等级（高/中/低） - “是否建议直接合入”的结论

这个模板核心是让 LLM 做“分析者”而非“决定者”。最终决定权仍然在维护者手里。

3.3 一个可落地的补丁审查流程

在实际项目中，比较推荐的流程是：

1. 开发者把驱动源码、TODO 文件、相关内核 API 文档手动整理好，作为上下文喂给 LLM。
2. LLM 生成初步修改建议或补丁草稿。
3. 开发者将补丁应用到临时分支，运行checkpatch.pl、sparse静态检查以及针对性的make编译。
4. 必要时在真实硬件或 QEMU 环境中跑一次基础功能测试。
5. 人工 review 后，再把补丁提交到内核邮件列表或公司的内部代码评审系统。

这样做的好处是：LLM 工作量集中在初稿和信息收集阶段，而最终的质量责任依然由人工承担，符合目前社区讨论的大方向。

4. 完整实战：用 LLM 分析并改进一个 staging 驱动

下面用一个相对完整的案例，演示如何把上面的思路落到实际操作中。为了便于理解，我们假设有一个名为staging/example_drv的驱动目录（实际路径以你的内核源码为准）。这里的重点是流程，不是某个具体驱动。

4.1 环境准备与代码获取

准备一台 Linux 开发机，建议安装以下工具：

• gcc、make、git
• 内核开发相关依赖（libncurses-dev、flex、bison等）
• 可选：sparse静态分析工具
• 一个 LLM 客户端或 API 环境，本地部署或调用云端 API 均可

获取内核源码：

git clone --depth 1 https://github.com/torvalds/linux.git cd linux

注意--depth 1只拉取最新一次提交，适合观察最新代码。如果需要针对特定版本分析，建议去掉该参数并切换到对应 tag。

4.2 让 LLM 先做代码结构梳理

打开drivers/staging/example_drv/目录，把关键文件内容粘贴给 LLM，先让模型回答整体结构：

这是一个 staging 驱动目录，文件结构如下： <粘贴目录树> 请根据代码分析： 1. 这个驱动的核心功能是什么，主要依赖哪些内核子系统？ 2. 目录里 TODO 文件提到的待办事项有哪些？ 3. 哪些文件之间是调用关系，能否画一个简单的 ASCII 依赖图？ 4. 根据你的判断，这个驱动距离移动到 drivers/ 主目录还有多大差距？

此时 LLM 的作用相当于“快速阅读源码并输出导读”。它给出的结果不一定完全准确，但可以帮开发者省去大量阅读时间。你需要做的是交叉验证关键结论，比如查看它提到的函数是否存在、调用关系是否合理。

4.3 用 LLM 生成清理补丁草稿

假设 TODO 文件里有一条：把printk(KERN_INFO ...)改成dev_info(...)。这是典型的重复机械任务，可以让 LLM 生成修改点：

以下是 drivers/staging/example_drv/main.c 的部分代码： <粘贴代码> 请把所有的 printk(KERN_INFO ...) 改为 dev_info(dev, ...)，并补充必要的 #include <linux/device.h>。 请只输出修改后的核心片段，不要添加解释。

拿到结果后，不要直接复制到源码里。更稳妥的做法是生成一个标准 diff 格式，然后用git apply测试：

# 开发者将 LLM 给出的修改内容保存为一个 patch 文件 git apply --check llm_cleanup.patch git apply llm_cleanup.patch

git apply --check会先检查补丁是否能干净地应用，如果提示冲突，说明模型生成的上下文和当前代码不一致，需要回退并重新调整。

4.4 使用内核工具验证代码质量

打完补丁之后，第一件事就是运行内核自带的补丁检查脚本checkpatch.pl。这个脚本能检测代码风格问题、可疑的结构、缺失的说明等，是内核社区最常见的自动检查工具之一。

./scripts/checkpatch.pl --no-tree --file drivers/staging/example_drv/main.c

如果补丁还没有合入，想检查补丁内容本身，可以运行：

git diff > /tmp/cleanup.patch ./scripts/checkpatch.pl /tmp/cleanup.patch

除了checkpatch.pl，还可以用sparse做基础静态分析：

make C=2 M=drivers/staging/example_drv

C=2是告诉内核构建系统使用 sparse 检查编译文件。运行后如果输出很多与本次修改无关的历史警告，可以暂时忽略，只关注本次修改涉及的文件和行号。

随后做一次具体的编译验证：

make ARCH=x86_64 defconfig make M=drivers/staging/example_drv

如果你的开发机没有完整内核配置，也可以用模块编译方式：

make ARCH=x86_64 M=drivers/staging/example_drv modules

这样会只编译指定路径下的模块，速度比全量编译快很多。

4.5 结果观察与提交

修改、验证完成后，确认差异：

git diff --stat git diff

如果确认无误，再写规范的提交信息：

git commit -s -m "staging: example_drv: replace printk with dev_info Use dev_info instead of printk(KERN_INFO ...) for better device context in log messages. No functional change. Signed-off-by: Your Name <your.email@example.com>"

提交信息中的Signed-off-by行是内核社区要求的来源证书，表明你有权提交该代码，并且对该补丁负责。如果使用了 LLM 辅助生成，可以在提交说明里简要补充，比如Generated with LLM assistance, manually reviewed and tested by <name>。

这部分操作目前没有统一的硬性格式要求，但透明始终比隐瞒好。

5. 常见问题与排查思路

5.1 关于“staging 代码能不能直接交给 LLM 重构”

很多朋友会问：为什么不让 LLM 一次性把 staging 目录清理干净？从结果上看，staging 里确实存在大量模式化代码，交给 LLM 做批量重构看起来很合理。但实际执行时往往会出现：

• 同一个变量在多个文件中被共享，LLM 只看单文件时容易误改；
• 有些代码看起来可以删除，实际上是某个老硬件的兼容逻辑；
• 批量修改后，仓库的 git 历史变得难以回溯，维护者 review 成本反而更高。

因此更稳妥的方式是：一次只处理一个小问题，比如先替换打印函数、再整理头文件、最后才动核心逻辑。每次改动都能独立编译、独立验证，出了问题也容易回退。

5.2 关于“LLM 分析驱动时上下文不够”

内核驱动很容易出现几万行代码，而 LLM 的上下文窗口是有限的。常见解决办法有两个：

1. 按文件粒度分析：让模型先分析核心入口文件，梳理函数调用关系，再按需查看被调函数。
2. 结合代码检索工具：在模型外部先定位关键函数、宏定义、结构体，再把相关内容填充到 prompt 中。

如果你在做团队内部的知识库，可以参考llm wiki的思路：把驱动目录、API 文档、常见问题整理成结构化卡片，让模型优先检索卡片，再基于卡片回答，而不是直接读整个源码。

6. 最佳实践与工程建议

6.1 提交策略与社区沟通

如果你准备把补丁发到内核社区，请务必注意：

• 先在小范围内说明是否使用了 LLM 辅助，不要隐瞒，也不要过度宣传。
• 每次提交尽量保持小步、独立、可 review。
• 不要用一个超大补丁同时完成“重构+修 bug+清理代码”，这类补丁无论是不是 AI 写的都很难通过社区评审。

6.2 代码审查与安全边界

在驱动开发中，安全边界比普通业务代码更敏感。尤其是涉及 DMA、中断、固件下载、寄存器操作的代码，建议遵循这些原则：

• LLM 生成的代码只能作为初稿，不能直接进入主线。
• 对 LLM 生成的代码，进行比人工代码更严格的审查，尤其是错误路径、超时处理、资源释放逻辑。
• 不要把 LLM Agent 的权限直接接到生产环境构建或硬件烧录环境。工具调用的最好设置在隔离沙箱中，避免模型因为上下文误判，执行危险命令。

如果你在安全测试环境中接触过“LLM API 过度授权”类靶场实验，会对这一点更有感触：模型本身可能没有问题，问题是给它的工具权限太大、缺少人工审批环节，容易导致链式错误。驱动开发也类似，建议把“构建、烧录、insmod/rmmod 模块”作为高风险操作，单独设置确认机制。

6.3 从驱动质量度量角度思考

与其纠结“能不能用 LLM”，不如把问题转换成“如何度量 LLM 参与生成的驱动质量”。可以考虑以下指标：

• 补丁通过checkpatch.pl的错误数；
• 是否能通过 sparse 和 W=1 级别编译告警；
• 是否提供了对应的设备树绑定文档或说明；
• 驱动是否能在至少一个模拟器或真实硬件环境中完成基本功能测试；
• 补丁合入后是否在稳定期内产生新增 bug report。

这些指标既能约束 LLM 的输出质量，也能帮助团队建立一套可复用的 AI 辅助开发流程。

6.4 知识沉淀与团队协作

在内核开发中，LLM 的价值不只是“写代码”，也包括知识沉淀。很多驱动维护者的经验存在大脑里，没有形成文档。可以把这些经验整理成 FAQ、检查清单、典型问题模板，导入团队的知识库系统。

这里可以借鉴llm wiki这样一种知识组织方式：把散落的经验变成可检索的条目，每条包含场景、原因、结论、相关代码链接。当模型需要回答开发问题之前，先让它在 wiki 里检索，再结合源码回答，这样既降低了幻觉率，也把个人经验转化成了团队资产。

6.5 生产环境注意事项

如果你的产品内核里有 staging 驱动，比如基于厂商 BSP 做嵌入式设备，需要注意：

• staging 驱动的质量等级默认低于正式驱动，上线前必须增加额外的测试覆盖。
• 不要因为驱动目录在 staging 里就忽略安全更新，漏洞修复补丁必须及时跟进。
• 如果要对 staging 驱动做 LLM 辅助重构，建议先在内部代码仓库验证，而不是直接改动交付给产线的内核分支。

7. 总结与学习路线

回到标题：LLM policy for drivers/staging/ going forward。目前内核社区并没有给出一个严格意义上的官方“LLM 政策”，但从讨论方向看，大家的共识已经比较清晰：LLM 是工具，不是作者；驱动代码最终由人和测试结果负责。在 staging 目录这种质量过渡区域，更应该优先采用“LLM 初稿 + 人工审查 + CI 验证”的流程，而不是让模型直接生成并合入完整驱动。

如果你正好对 LLM 辅助内核开发感兴趣，建议按这条路线往下走：

1. 先熟悉drivers/staging目录下的一个简单驱动，读完它的 TODO 文件，尝试手动完成一两个清理任务，对代码风格建立体感。
2. 在本地搭建一个 LLM 辅助环境，把常用的内核文档、一份驱动源码、checkpatch.pl检查规则整理成提示词模板。
3. 动手做一个真实的“小步重构”练习，比如把printk替换为dev_dbg，跑完编译和checkpatch，再对比人工写补丁的效率差异。
4. 再进阶可以尝试把驱动代码库和文档接入 RAG，让模型能够回答“某个 API 在哪个版本引入”“某个驱动如何解决中断共享问题”这类查询型问题。

从落地角度来看，现阶段最稳妥的姿势不是“让 AI 写驱动”，而是“用 AI 读懂驱动、辅助驱动审查、加速驱动清理”。这也是未来内核开发中，LLM 工具链最可能被主流接受的方向。

希望这篇文章能帮你理清drivers/staging与 LLM 的关系，也给你一些可以直接上手的工具和流程。如果你最近也在尝试 LLM 辅助内核开发，或者手头正在维护 staging 驱动，欢迎在评论区聊聊你的踩坑经历。