Linux无线子系统抵制AI垃圾补丁：驱动开发与提交正确姿势

各位读者朋友大家好。最近 Linux Wireless 子系统维护者在邮件列表里对 AI 生成的“垃圾补丁”明确表态态度非常坚决。这件事在开源社区里讨论度很高但很多新手并不清楚为什么维护者反应这么大也不明白“AI 生成的补丁”到底差在哪里。本文会从这次事件出发把 Linux wireless 子系统的补丁提交流程、无线驱动开发环境的准备、补丁格式规范、AI 生成补丁的常见问题以及如何正确使用 AI 辅助开发全部梳理一遍。无论你是 Linux 内核初学者、嵌入式开发者还是平时需要编译 Realtek、Intel、Qualcomm 无线网卡驱动的用户这篇文章都值得收藏。1. 事件背景无线子系统维护者对 AI 补丁亮出红线1.1 发生了什么Linux 内核的无线子系统由专门的维护者负责其中 Kalle Valo 长期维护 ath 系列驱动以及整个 wireless 子系统的收尾工作。近期linux-wireless 邮件列表里出现了不少带着“AI 生成痕迹”的补丁提交内容看起来格式工整、排版漂亮但仔细审查就会发现没有真实的硬件测试、没有编译验证、代码逻辑经不起推敲甚至提交信息里的描述和实际改动完全对不上。维护者对此的态度非常直接这类补丁不仅不会加快内核开发反而会严重消耗维护者的人工审查时间。你要知道内核维护者每天要看的补丁数量非常大一个“看起来不错但实际不能用”的补丁比一个“明确说清楚我没测试”的补丁更让人头疼。因为前者需要维护者逐行排查才能发现问题后者一眼就能拒绝。1.2 为什么无线子系统特别重视补丁质量无线子系统是 Linux 内核里硬件相关性最强的区域之一。一个驱动补丁不只是“改几行 C 代码”它直接影响网卡能否被识别WiFi 连接是否稳定功耗管理是否正确是否引入内存越界、空指针解引用等安全漏洞是否能支持新的无线芯片型号。更关键的是无线驱动往往只能由持有对应硬件的开发者测试。维护者不可能为了验证一个补丁专门去买一块 Realtek 8821CE 或者 Intel AX200 网卡。所以社区默认规则是提交者必须自己完成编译和基本功能验证并在补丁中说明测试环境。如果补丁来源是 AI 自动生成、没有经过任何硬件验证那它在维护者眼里就属于“需要人工擦屁股的负担”。2. 先搞清楚Linux wireless 子系统里都有什么2.1 子系统覆盖的驱动范围Linux 内核的 wireless 子系统非常庞大从目录结构上就能看出来。我们平时接触的无线网卡驱动主要有以下几条线驱动系列常见芯片说明ath9k / ath10k / ath11kQualcomm Atheros从老款 AR956x 到新款高通平台iwlwifiIntel WirelessIntel AC 9560、AX200 等rtw88 / rtw89Realtek8821CE、8822CE、8852BE 等mt76MediaTekMT76x2、MT7921 等brcmfmacBroadcom常见于树莓派和部分笔记本从最近搜索热度也能看出很多 Linux 用户手里就是 Realtek 8821CE、8822CE、8852BE 这类无线网卡装上 Linux 后发现 WiFi 无法使用于是到处找驱动。这些驱动有的已经进入内核主线rtw88 支持 8821CE、8822CE有的则需要使用厂商提供的 out-of-tree 驱动rtw89 部分早期版本。2.2 无线补丁进入主线的路径一个无线驱动补丁从提交到合入大致走过下面几条路开发者在内核源码上修改drivers/net/wireless/下的代码本地编译通过后用git format-patch生成补丁文件将补丁发送到linux-wirelessvger.kernel.org子系统维护者审核必要时通过wireless-next分支合入经过 linux-next 集成测试后进入主线再通过 stable 机制回移植到长期维护版本。这个流程里维护者审核是绝对的人工环节。AI 可以生成补丁但无法替维护者承担“这个改动是否可靠”的责任。所以当大量 AI 补丁涌入时维护者选择直接拒绝本质上是在保护整个流程的可维护性。3. 一个合格的无线驱动补丁应该长什么样3.1 补丁的组成结构内核补丁不是随便贴一段 diff 就完事。一个标准补丁包含三部分提交信息commit message说明“为什么改”代码改动diff说明“改了什么”签名信息说明“谁改的、如何测试的”。下面是一个合格的无线驱动补丁示例假设我们要修复 rtw88 驱动的某个电源管理问题rtw88: fix null pointer dereference in power save mode When entering power save mode, the firmware may send a PS state notification before the associated station is fully initialized. In that case, sta-drv_priv is still NULL, which leads to a null pointer dereference in rtw_sta_psy_update(). Fix it by adding a NULL check before accessing drv_priv. Tested-on: Realtek 8822CE, connect/disconnect 100 times Signed-off-by: Zhang San zhangsanexample.com注意看这段提交信息里的几个关键点第一行是子系统: 简短的标题不能超过 75 个字符空一行后是正文说明问题和原因Tested-on说明在哪里测试过最后是Signed-off-by签名。3.2 提交信息为什么重要维护者第一眼看的不是 diff而是提交信息。如果提交信息说得含糊不清或者描述的内容和 diff 不一致那维护者大概率直接回一句 “NACK” 或者要求重新解释。AI 生成的补丁最常见的破绽就在提交信息上AI 会生成非常流利的英文描述但描述里的“bug 场景”往往是编造的。比如它可能写“修复了内存泄漏”但用户看 diff 时发现根本没有释放内存的改动。这种不一致是非常严重的警告信号。3.3 代码风格与 checkpatch 校验内核代码有严格的风格要求内核源码里自带了scripts/checkpatch.pl脚本。提交之前必须过一遍./scripts/checkpatch.pl my-patch.patch如果补丁格式正确输出大致如下total: 0 errors, 0 warnings, 21 lines checked如果存在风格问题checkpatch 会明确指出行号和错误类型。常见问题包括超过 80 字符的代码行使用//注释而不是/* */不必要的空行缩进使用了空格而不是 Tab新增代码缺少必要的空行分隔。不要小看这些细节。无线子系统维护者每天看大量补丁风格不统一的补丁会显著增加阅读成本。4. 手把手演示从修改到提交补丁4.1 准备内核源码与编译环境如果你想往 Linux wireless 提补丁首先要有一个能编译的内核源码树。以长期维护版本为例# 克隆内核主线仓库 git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux # 切换到长期维护分支比如 6.6.y git remote add stable https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git git fetch stable # 创建自己的开发分支 git checkout -b my-wireless-fix stable/linux-6.6.y编译内核需要安装基础工具链Debian/Ubuntu 上通常这样安装sudo apt install build-essential flex bison libssl-dev libelf-dev \ libncurses-dev bc接着配置内核。如果你想编译无线驱动需要打开对应的配置项。例如 Realtek 8821CE 对应 rtw88 驱动# 生成默认配置 make defconfig # 通过 menuconfig 手动打开选项 make menuconfig在 menuconfig 里进入Device Drivers - Network device support - Wireless LAN找到Realtek rtl8xxxw88 (rtw88) wireless driver support把 8821CE 对应的RTL8821CE选项选中为M编译为模块。也可以直接在.config里确认grep RTW88 .config预期输出类似CONFIG_RTW88y CONFIG_RTW88_8821CEm4.2 修改驱动代码假设你在 rtw88 驱动源码中定位到一个问题。修改完成后先用git diff检查改动是否符合预期git diff drivers/net/wireless/realtek/rtw88/这一步非常重要。AI 生成补丁最常见的问题之一就是它不会告诉你它改了什么你拿到后也不去核对。如果你是自己手动修改一定要在git diff阶段确认改动范围没有夹带其它无关内容。4.3 生成补丁改动确认无误后提交到本地分支并生成补丁git add drivers/net/wireless/realtek/rtw88/ git commit -s注意-s会自动添加Signed-off-by。提交信息按上一节讲的规范填写。然后生成补丁文件git format-patch -1 -o /tmp/my-patches/这时会在/tmp/my-patches/下生成一个0001-xxx.patch文件。先跑一遍 checkpatch./scripts/checkpatch.pl /tmp/my-patches/*.patch确认没有错误后再把补丁通过邮件发送到linux-wireless邮件列表。这里推荐用git send-emailgit send-email --to linux-wirelessvger.kernel.org \ --cc linux-kernelvger.kernel.org \ /tmp/my-patches/0001-xxx.patch4.4 补丁提交后的心理预期提交补丁只是第一步。无线子系统维护者通常非常忙补丁从提交到收到回复可能需要几天甚至几周。如果收到 Review 意见不要着急逐条回应并修改。内核社区的讨论文化是“对事不对人”只要你的补丁是真实可验证的维护者会给出非常具体的改进建议。5. AI 生成补丁的典型问题与分析下面我来拆解为什么维护者会对 AI 补丁这么反感。所谓 “AI slop patches”并不是说 AI 写的代码 100% 是坏的而是指它们整体上存在几类非常致命的问题。5.1 看起来合理但语义错误AI 大模型擅长生成“语法正确”的 C 代码但它不理解硬件行为。无线驱动里充满了寄存器操作、固件交互、DMA 描述符管理、电源状态机等底层逻辑。AI 生成的代码常常在语义层面出错例如把readl和writel的顺序写反在中断上下文里调用了可能睡眠的函数错误地假设某个结构体成员一定存在修改了锁的范围但没有说明为什么。这类问题在 code review 阶段极难发现因为代码风格可能是规范的甚至能通过编译但运行时会随机崩溃。5.2 没有编译验证很多 AI 工具根本不知道目标网卡的硬件环境提交者也没有实际编译测试直接把输出贴到邮件列表里。内核社区对没有Tested-by、没有编译说明的补丁本来就持怀疑态度AI 补丁往往连“编译通过”这个最基本的门槛都过不了。举个例子如果 AI 用了一个devm_krealloc()但对应的内核版本比较老这个函数可能不存在编译直接失败。这种错误只要执行一次make就能发现但很多提交者连这一步都没做。5.3 提交信息胡编乱造前面说过提交信息是维护者判断补丁质量的第一窗口。AI 生成补丁时经常编造“为什么这样修改”的理由。比如写“修复在 unload 时可能发生的 use-after-free”但实际代码里根本没有释放操作。这种“看起来专业的胡说八道”是最消耗维护者精力的因为维护者需要逐行对比 commit message 和 diff。5.4 批量提交污染跟踪系统更让维护者头疼的是AI 工具低成本生成补丁导致有人一次性提交几十个“微小改动”每一个都把“优化性能”“提高稳定性”这种抽象理由当成挡箭牌。这些补丁单个看起来无害但批量涌入时会淹没真正有价值的补丁让维护者不得不花大量时间去筛选。6. 常见问题排查这一节针对无线驱动开发和补丁提交过程中经常遇到的问题做一个快速排查表。6.1 补丁被拒后怎么办问题现象常见原因解决思路维护者回复 NACK补丁逻辑错误或格式不规范先跑 checkpatch再逐条回应 Review 意见补丁没有收到任何回复邮件被过滤或维护者排队中等待 1-2 周后礼貌催问不要重复提交补丁落到主线后编译失败没有做全量编译验证重新拉取最新代码确认依赖环境6.2 checkpatch 报错问题现象常见原因解决思路WARNING: line over 80 characters代码行太长手动换行保持可读性ERROR: code indent should use tabs用了空格缩进编辑器切成 Tab 缩进ERROR: Missing Signed-off-by提交时忘了-sgit commit --amend -s后重新生成补丁6.3 无线驱动加载失败很多读者可能不是要提交补丁只是自己的无线网卡在 Linux 下无法工作。常见排查如下# 查看无线网卡是否被识别 lspci -nnk | grep -i network # 查看内核是否加载对应驱动模块 lsmod | grep rtw # 手动加载驱动模块 sudo modprobe rtw88_8821ce如果lspci能看到设备但lsmod没有对应模块说明内核配置里没有编译该驱动。你需要回到 4.1 节重新配置内核或者安装对应的 dkms 驱动包。7. 最佳实践如何正确使用 AI 辅助而不是制造垃圾补丁关于 AI 和开源开发的关系我个人的态度是AI 可以当助手不能当作者。用 AI 提高效率没有问题关键是你要对产出结果负责。7.1 让 AI 做分析而不是“写补丁”更好的用法是把 AI 当作解释器和排查工具。比如你拿到一个无线驱动的崩溃日志可以先把日志贴给 AI让它帮你分析可能的原因也可以让 AI 解释某个内核 API 的语义。这些场景下 AI 的误差不会直接进入代码树。如果你确实想让 AI 生成补丁初稿请务必遵守下面几条生成后逐行阅读确认每个改动都能说出理由在当前内核源码树上实际编译修复报错如果有条件在真实网卡上做功能测试在提交信息里如实说明测试情况。不要写“Tested-by: AI”这没有任何意义。7.2 提交前的必备检查清单我建议每位开发者养成下面的习惯每次提交无线驱动补丁之前过一遍代码是否基于最新分支而不是几个月前的旧代码git diff是否干净没有夹带无关文件提交信息是否有清晰的问题描述和测试说明checkpatch.pl是否 0 error是否在真实硬件上做过基本功能验证补丁是否只发送到正确的邮件列表7.3 社区协作礼仪内核社区是一个高度依赖信任的协作环境。维护者的时间非常宝贵每一个补丁都是提交者在消耗维护者的注意力。因此补丁宁缺毋滥不要为了“刷贡献”而提交收到批评时不要情绪化用技术事实回应如果你没有硬件可以测试明确说“这个补丁没有经过硬件验证”请维护者帮忙把关或者等待有硬件的人来测试永远不要在提交信息里虚构测试结果。8. 总结与学习路线Linux Wireless 维护者反对 AI 生成的垃圾补丁本质上不是反对 AI 工具而是反对“不对结果负责的提交行为”。内核开发的核心从来不是代码生成而是可验证、可解释、可维护。AI 能帮助开发者更快地理解代码、分析问题、写出初稿但最终的决定权和责任永远在提交者身上。如果你想深入了解无线子系统开发建议按这个顺序学习先掌握 Git 和内核编译流程能自己编译出可用的无线驱动模块阅读Documentation/process/submitting-patches.rst完整理解补丁规范跟着drivers/net/wireless/里某个驱动的维护者提交记录观察真实 Review 过程从文档修正、注释补充、测试补充这类低风险改动开始逐步建立社区信任有真实硬件后再尝试提交功能修复或新硬件支持。内核社区需要的是认真、负责、愿意动手验证的贡献者。看完这篇文章建议你先从编译一个自己的内核开始把你手里那台装了 Realtek 或 Intel 无线网卡的机器变成你的第一块试验田。等到你对补丁流程有了体感再回头看你之前提交的东西可能自己都能发现很多问题——这本身就是成长的开始。如果这篇文章对你有帮助欢迎收藏也欢迎在评论区交流你的无线驱动调试经历。