Linux 6.17 怎样筛选驱动变化

Linux 6.17 的驱动改动很多，直接从 13 MB 左右的完整变更日志里找某个网卡、显卡或存储控制器，通常会被无关提交淹没。更稳妥的做法是先固定比较范围，再按 drivers/ 下的子系统目录过滤，最后回到 Kconfig、模块名和硬件 ID 判断“这条变化是否真的影响我的设备”。

筛选 Linux 6.17 驱动变化，可以按“版本基线 → 子系统路径 → 提交类型 → 配置与设备匹配”四层收敛。只看提交标题不够，至少要确认它改变了哪个驱动目录、哪个配置项，以及目标设备是否能匹配到该驱动。

官方地址：https://www.kernel.org/

本文采用 Linux 6.16 到 Linux 6.17 的主线差异作为示例。Linux 6.17 发布后的 6.17.x 稳定版本会继续包含修复，若要写“某个稳定版本新增了什么”，应另外比较对应的稳定分支，不能把它们和主线合并描述。

先分清要查的是主线变化还是稳定修复

Linux 内核归档同时提供版本源码包、ChangeLog 和后续稳定版本文件。对“Linux 6.17 有哪些驱动变化”这种问题，第一步应固定为 v6.16..v6.17；对“6.17.7 修复了什么”，则应固定为 v6.17.6..v6.17.7。两个范围回答的不是同一个问题。

主线资料：https://www.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.17

内核源码树：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

官方归档页面把 ChangeLog-6.17、linux-6.17.tar.xz 和后续 6.17.x 文件分开列出。先选对文件，能避免把稳定回补、发行版补丁和主线合并提交混成一张“新功能清单”。

用 drivers 路径把候选提交缩小

如果本地已经有 Linux 源码仓库，可以先查看目录级统计，再读取具体提交。第一条命令回答“哪些驱动目录变了”，第二条命令回答“这些目录里有哪些提交”。

# 统计 6.16 到 6.17 期间 drivers/ 下各路径的改动规模
git diff --stat v6.16..v6.17 -- drivers/

# 只列出驱动相关提交；--no-merges 减少合并提交造成的重复噪声
git log --no-merges --format='%h%x09%s' v6.16..v6.17 -- drivers/

接着按自己的硬件把范围缩到子系统。例如无线网卡优先看 drivers/net/wireless/，显卡看 drivers/gpu/，NVMe 和 SCSI 则分别看 drivers/nvme/、drivers/scsi/。不要一开始就按厂商名全文搜索，因为提交标题可能写的是通用框架、PCI ID 或平台代号。

# 只看无线、显卡和存储三个方向的提交标题
git log --no-merges --format='%h %ad %s' --date=short \
  v6.16..v6.17 -- \
  drivers/net/wireless drivers/gpu drivers/nvme drivers/scsi

# 将某个提交展开到文件级，确认它确实改到了目标驱动
git show --stat --summary COMMIT_ID

这一步的结果应当是一份候选列表，而不是最终结论。驱动子系统中既有新硬件支持，也有公共代码重构、构建修复、文档更新和测试调整，它们对使用者的影响完全不同。

按新增、修改、删除和硬件 ID 变化分类

筛选时建议先看文件状态，再看提交正文。新增文件通常提示新驱动或新平台支持；修改文件可能只是修复，也可能加入新能力；删除文件需要确认是旧驱动移除、重复实现清理，还是目录迁移。

# 查看驱动文件在版本范围内的新增、修改和删除状态
git diff --name-status v6.16..v6.17 -- drivers/

# 找出新增文件的提交，便于区分新驱动与已有驱动改造
git log --diff-filter=A --summary v6.16..v6.17 -- drivers/

# 搜索常见的设备匹配线索；结果仍需回到具体提交确认
git log --oneline v6.16..v6.17 -- drivers/ | \
  grep -Ei 'pci|usb|of|acpi|id|firmware|support'

Linux 6.17 的公开变更摘要把驱动部分分成图形、电源管理、存储、Staging、网络、音频等组，并列出了 NVMe 管理控制器、无线驱动更新、蓝牙 USB ID、媒体格式和解码器等不同类型的条目。这些条目适合拿来建立阅读索引，但不能仅凭摘要判断某一台机器是否会获得新功能。

真正需要确认的是三个问题：提交有没有新增设备 ID；驱动的 Kconfig 是否默认启用；发行版内核是否把它编译成内置代码或模块。只有这三项和目标硬件对上，才值得继续看运行时影响。

用 Kconfig、模块名和设备匹配确认影响

提交标题中的“support”并不等于当前系统立即可用。驱动可能依赖实验性配置、特定总线或固件。阅读具体提交时，优先跟踪 Kconfig、Makefile、PCI/USB/OF/ACPI ID 表和固件加载路径。

# 从内核配置中确认目标驱动是内置、模块还是未启用
grep -E 'CONFIG_(DRIVER_NAME|BUS_NAME)=' .config

# 查看已安装模块的别名、固件依赖和版本信息
modinfo DRIVER_MODULE | sed -n '/^alias:/p;/^firmware:/p;/^version:/p'

# 读取设备当前绑定的驱动；没有绑定时不要把它误判成新版本缺失
readlink /sys/bus/pci/devices/0000:00:00.0/driver || true

上面的命令只用于把“源码变化”映射到“配置和设备”。如果目标是新闻解读，可以把结论写成“新增了某类支持”“扩大了设备匹配范围”或“修复了某路径的异常”，不要没有证据就写成“所有发行版都已启用”或“性能一定提升”。

还要注意内核内部接口并不承诺稳定的二进制兼容。Linux 内核文档明确区分了用户空间接口和内核内部接口；外部驱动是否能在 6.17 上继续构建，不能只看模块文件名，还要看它使用的内核 API、发行版补丁和构建配置。

最后用一张表沉淀筛选结论

对每个候选驱动保留一行记录，后续无论是写升级说明、做发行版适配还是排查设备不识别，都比复制一长串提交标题更有用。

如果只想快速得到一份可读清单，可以先用 ChangeLog 和社区整理页找方向，再回到 Linux Git 树检查路径、提交和配置。这样既保留了新闻摘要的效率，也不会把“出现在变更日志里”误写成“当前机器已经受益”。

常见问题

Linux 6.17 的 ChangeLog 能直接当驱动清单吗？ 不能。它适合做入口，最终仍要按 drivers/ 路径和具体提交过滤。

只搜索显卡或网卡厂商名够不够？ 不够。驱动变化可能写在公共框架、总线代码、设备 ID 表或平台代号中，建议先按子系统路径，再按厂商和设备线索缩小。

6.17.x 稳定版的驱动修复算不算 Linux 6.17 新功能？ 不应直接这样写。主线新能力和稳定分支回补要分别标注版本区间。

怎样判断某条变化会不会影响我的机器？ 对照设备总线和 ID、Kconfig 状态、模块别名、固件依赖以及当前驱动绑定情况，至少确认其中的因果链闭合。