最近在整理内核开发相关笔记时重新看到了一个很有意思的议题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”到底在讨论什么翻译成直白的中文这个讨论大致聚焦在三个层面提交政策开发者使用 LLM 生成的代码提交到内核邮件列表时是否需要主动披露社区是否接受纯 AI 生成的驱动质量政策LLM 生成的代码是否必须通过额外的静态检查、构建测试、维护者人工 review维护责任当一块驱动主要由 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 一个可落地的补丁审查流程在实际项目中比较推荐的流程是开发者把驱动源码、TODO 文件、相关内核 API 文档手动整理好作为上下文喂给 LLM。LLM 生成初步修改建议或补丁草稿。开发者将补丁应用到临时分支运行checkpatch.pl、sparse静态检查以及针对性的make编译。必要时在真实硬件或 QEMU 环境中跑一次基础功能测试。人工 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.patchgit 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 C2 Mdrivers/staging/example_drvC2是告诉内核构建系统使用 sparse 检查编译文件。运行后如果输出很多与本次修改无关的历史警告可以暂时忽略只关注本次修改涉及的文件和行号。随后做一次具体的编译验证make ARCHx86_64 defconfig make Mdrivers/staging/example_drv如果你的开发机没有完整内核配置也可以用模块编译方式make ARCHx86_64 Mdrivers/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.emailexample.com提交信息中的Signed-off-by行是内核社区要求的来源证书表明你有权提交该代码并且对该补丁负责。如果使用了 LLM 辅助生成可以在提交说明里简要补充比如Generated with LLM assistance, manually reviewed and tested by name。这部分操作目前没有统一的硬性格式要求但透明始终比隐瞒好。5. 常见问题与排查思路问题现象常见原因解决思路git apply提示补丁无法应用模型基于旧版本源码生成上下文对齐内核版本重新生成补丁或手动合并冲突checkpatch.pl报错数量很多模型不熟悉内核编码风格在 prompt 中补充 coding-style 摘要先手动修正前几个错误再让模型学习编译报错implicit declaration of function缺少对应的头文件或内核配置未开启检查源码依赖和 Kconfig 配置必要时打开相关 config构建时出现 VLA 相关错误内核默认禁用变长数组VLA让 LLM 改成固定大小数组或使用kmalloc动态分配sparse 报context imbalance函数锁的获取和释放路径不一致人工检查加锁与解锁路径不要让 LLM 直接改LLM 生成的补丁能编译但运行时崩溃上下文缺失导致对硬件行为理解错误用 QEMU 或真实硬件做最小复现回退补丁逐步定位开发者担心 LLM 代码版权与许可证问题模型训练数据来源不可控保持补丁可追溯补充使用说明重要代码仍由人重写5.1 关于“staging 代码能不能直接交给 LLM 重构”很多朋友会问为什么不让 LLM 一次性把 staging 目录清理干净从结果上看staging 里确实存在大量模式化代码交给 LLM 做批量重构看起来很合理。但实际执行时往往会出现同一个变量在多个文件中被共享LLM 只看单文件时容易误改有些代码看起来可以删除实际上是某个老硬件的兼容逻辑批量修改后仓库的 git 历史变得难以回溯维护者 review 成本反而更高。因此更稳妥的方式是一次只处理一个小问题比如先替换打印函数、再整理头文件、最后才动核心逻辑。每次改动都能独立编译、独立验证出了问题也容易回退。5.2 关于“LLM 分析驱动时上下文不够”内核驱动很容易出现几万行代码而 LLM 的上下文窗口是有限的。常见解决办法有两个按文件粒度分析让模型先分析核心入口文件梳理函数调用关系再按需查看被调函数。结合代码检索工具在模型外部先定位关键函数、宏定义、结构体再把相关内容填充到 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 和 W1 级别编译告警是否提供了对应的设备树绑定文档或说明驱动是否能在至少一个模拟器或真实硬件环境中完成基本功能测试补丁合入后是否在稳定期内产生新增 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 辅助内核开发感兴趣建议按这条路线往下走先熟悉drivers/staging目录下的一个简单驱动读完它的 TODO 文件尝试手动完成一两个清理任务对代码风格建立体感。在本地搭建一个 LLM 辅助环境把常用的内核文档、一份驱动源码、checkpatch.pl检查规则整理成提示词模板。动手做一个真实的“小步重构”练习比如把printk替换为dev_dbg跑完编译和checkpatch再对比人工写补丁的效率差异。再进阶可以尝试把驱动代码库和文档接入 RAG让模型能够回答“某个 API 在哪个版本引入”“某个驱动如何解决中断共享问题”这类查询型问题。从落地角度来看现阶段最稳妥的姿势不是“让 AI 写驱动”而是“用 AI 读懂驱动、辅助驱动审查、加速驱动清理”。这也是未来内核开发中LLM 工具链最可能被主流接受的方向。希望这篇文章能帮你理清drivers/staging与 LLM 的关系也给你一些可以直接上手的工具和流程。如果你最近也在尝试 LLM 辅助内核开发或者手头正在维护 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”到底在讨论什么翻译成直白的中文这个讨论大致聚焦在三个层面提交政策开发者使用 LLM 生成的代码提交到内核邮件列表时是否需要主动披露社区是否接受纯 AI 生成的驱动质量政策LLM 生成的代码是否必须通过额外的静态检查、构建测试、维护者人工 review维护责任当一块驱动主要由 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 一个可落地的补丁审查流程在实际项目中比较推荐的流程是开发者把驱动源码、TODO 文件、相关内核 API 文档手动整理好作为上下文喂给 LLM。LLM 生成初步修改建议或补丁草稿。开发者将补丁应用到临时分支运行checkpatch.pl、sparse静态检查以及针对性的make编译。必要时在真实硬件或 QEMU 环境中跑一次基础功能测试。人工 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.patchgit 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 C2 Mdrivers/staging/example_drvC2是告诉内核构建系统使用 sparse 检查编译文件。运行后如果输出很多与本次修改无关的历史警告可以暂时忽略只关注本次修改涉及的文件和行号。随后做一次具体的编译验证make ARCHx86_64 defconfig make Mdrivers/staging/example_drv如果你的开发机没有完整内核配置也可以用模块编译方式make ARCHx86_64 Mdrivers/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.emailexample.com提交信息中的Signed-off-by行是内核社区要求的来源证书表明你有权提交该代码并且对该补丁负责。如果使用了 LLM 辅助生成可以在提交说明里简要补充比如Generated with LLM assistance, manually reviewed and tested by name。这部分操作目前没有统一的硬性格式要求但透明始终比隐瞒好。5. 常见问题与排查思路问题现象常见原因解决思路git apply提示补丁无法应用模型基于旧版本源码生成上下文对齐内核版本重新生成补丁或手动合并冲突checkpatch.pl报错数量很多模型不熟悉内核编码风格在 prompt 中补充 coding-style 摘要先手动修正前几个错误再让模型学习编译报错implicit declaration of function缺少对应的头文件或内核配置未开启检查源码依赖和 Kconfig 配置必要时打开相关 config构建时出现 VLA 相关错误内核默认禁用变长数组VLA让 LLM 改成固定大小数组或使用kmalloc动态分配sparse 报context imbalance函数锁的获取和释放路径不一致人工检查加锁与解锁路径不要让 LLM 直接改LLM 生成的补丁能编译但运行时崩溃上下文缺失导致对硬件行为理解错误用 QEMU 或真实硬件做最小复现回退补丁逐步定位开发者担心 LLM 代码版权与许可证问题模型训练数据来源不可控保持补丁可追溯补充使用说明重要代码仍由人重写5.1 关于“staging 代码能不能直接交给 LLM 重构”很多朋友会问为什么不让 LLM 一次性把 staging 目录清理干净从结果上看staging 里确实存在大量模式化代码交给 LLM 做批量重构看起来很合理。但实际执行时往往会出现同一个变量在多个文件中被共享LLM 只看单文件时容易误改有些代码看起来可以删除实际上是某个老硬件的兼容逻辑批量修改后仓库的 git 历史变得难以回溯维护者 review 成本反而更高。因此更稳妥的方式是一次只处理一个小问题比如先替换打印函数、再整理头文件、最后才动核心逻辑。每次改动都能独立编译、独立验证出了问题也容易回退。5.2 关于“LLM 分析驱动时上下文不够”内核驱动很容易出现几万行代码而 LLM 的上下文窗口是有限的。常见解决办法有两个按文件粒度分析让模型先分析核心入口文件梳理函数调用关系再按需查看被调函数。结合代码检索工具在模型外部先定位关键函数、宏定义、结构体再把相关内容填充到 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 和 W1 级别编译告警是否提供了对应的设备树绑定文档或说明驱动是否能在至少一个模拟器或真实硬件环境中完成基本功能测试补丁合入后是否在稳定期内产生新增 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 辅助内核开发感兴趣建议按这条路线往下走先熟悉drivers/staging目录下的一个简单驱动读完它的 TODO 文件尝试手动完成一两个清理任务对代码风格建立体感。在本地搭建一个 LLM 辅助环境把常用的内核文档、一份驱动源码、checkpatch.pl检查规则整理成提示词模板。动手做一个真实的“小步重构”练习比如把printk替换为dev_dbg跑完编译和checkpatch再对比人工写补丁的效率差异。再进阶可以尝试把驱动代码库和文档接入 RAG让模型能够回答“某个 API 在哪个版本引入”“某个驱动如何解决中断共享问题”这类查询型问题。从落地角度来看现阶段最稳妥的姿势不是“让 AI 写驱动”而是“用 AI 读懂驱动、辅助驱动审查、加速驱动清理”。这也是未来内核开发中LLM 工具链最可能被主流接受的方向。希望这篇文章能帮你理清drivers/staging与 LLM 的关系也给你一些可以直接上手的工具和流程。如果你最近也在尝试 LLM 辅助内核开发或者手头正在维护 staging 驱动欢迎在评论区聊聊你的踩坑经历。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
