今日重点：🔍 标题解析——这是第三篇标题解析，今天换个角度： 不讲动词表，讲「同一个意思的粒度差异」。 今天光「加个东西」这一件事，邮件列表上就有六种写法——而它们不能互换， 因为加的是「一个对象」还是「一种能力」还是「一个格式宏」，决定了标题长什么样。

📖 今日标题（真实清单，逐字引用）

/ section
[PATCH v5 0/6] rust: Add drm::JobQueue [PATCH 2/3] media: i2c: Add GC8034 image sensor driver [PATCH v2 00/20] drm/msm/dp: Add static HDR support for DP and eDP [PATCH] media: imx-mipi-csis: add support for MEDIA_BUS_FMT_YUYV8_1X16 [PATCH 3/3] media: ipu-bridge: Add GalaxyCore GC5035 and GC8034 [PATCH net-next v9 00/11] Support for onsemi's S2500 10Base-T1S MAC-PHY [PATCH 3/3] media: mt9v032: Add get_mbus_config subdev_pad_ops callback

出处：均取自 2026-10-10 的全内核雷达（lore.kernel.org 13 列表，近 24h）。 各自的原文链接见下方逐条拆解与练习。

🔍 六种写法：粒度决定形状

/ column
① Add <对象> —— 加一个实体 Add drm::JobQueue（一个 Rust 类型）、Add GC8034 image sensor driver（一个驱动）。加的是「一个能独立命名、独立存在的东西」时用这种：Add 后面直接跟那个东西的名字，不加 support、不加 for。这类标题最短，因为对象本身已经把话说完了。原文
② Add X support for Y —— 加一种能力，且要指明给谁 Add static HDR support for DP and eDP。注意这里 support 出现在标题里，是因为「支持」本身是被加的东西——HDR 不是一个独立对象，而是一种能力，且必须说清给哪两个接口（DP 和 eDP）。对照 ①：① 里不需要 support，因为驱动/类型就是那个东西本身。原文
③ add support for <一个宏> —— 细到一个格式常量 add support for MEDIA_BUS_FMT_YUYV8_1X16。粒度细到单个宏名——给已有驱动多认一种 media bus 格式。这类改动很小，标题也就把那个宏原样写出来，不解释、不概括。看到标题里出现全大写的宏名，通常就是这种「给已有代码多认一个值」的补丁。原文
④ Add A and B —— 并列两项 Add GalaxyCore GC5035 and GC8034。一次加两个同类对象时，用 and 并列，不加逗号、不缩写。注意这条标题没有任何 support/for 修饰——因为加的是两颗具体传感器，对象说话已经够了。原文
⑤ Support for X —— 纯名词，没有动词 Support for onsemi's S2500 10Base-T1S MAC-PHY。整条标题没有动词，只有名词短语。什么时候可以这么写？当交付的是一份完整支持（新驱动 + 绑定 + 接线，一整套），而不是对既有代码的增量改动时。它强调「这是一份支持」，与 Add X 的语境有别。提醒：这属少数派写法，新人仍建议用祈使句。原文
⑥ Add <回调名> —— 加一个接口实现 Add get_mbus_config subdev_pad_ops callback。加的是一个具名回调，标题里连它属于哪个 ops 结构体都写出来了（subdev_pad_ops）。这类改动是「实现框架要求的某一条」，粒度比 ③ 粗、比 ① 细，写法上也不加 support。原文

✨ 辅助彩蛋：地道表达

/ column

★ 标题里的四个小词，各自承担一层信息

都出自今天这几个真实标题

a range of 原文：fix a range of UAFs during rcu pathwalk。a range of 比 some 更有分量——它暗示这些问题是成体系的、覆盖一个区间的，不是零散碰到几个。写修复合集时，用 a range of 能让维护者知道这不是随机捡的。
caused by 原文：UAFs during rcu pathwalk caused by non-rcu frees。归因句式。标题里出现 caused by，等于当场回答了「谁引起的」——维护者读到这里就不用再问「为什么路径上会有非 RCU 释放」。
redesign 与 rework 原文：zram: redesign zcomp and rework backends。两个 re- 动词轻重不同：redesign 是重新设计（动结构），rework 是翻工重做（动实现）。一条标题里同时用两个，说明作者在区分「哪部分改了设计、哪部分只是重写」——这个区分对评审有用。
undo 原文：make the mapping functions undo their partial mappings。undo 在这里不是「撤销操作」，而是「回滚已做的部分工作」——分配失败时把已经建好的半截映射拆掉。内核里说回滚，undo 比 revert 更常指这种「自己清理自己」的动作。

✍️ 今日练习

/ column
✍️ 给四个场景各写一条标题，注意粒度决定写法（都要带子系统前缀）：① 新增一个 Rust 的 DMA 缓冲类型；② 给已有的 SPI 驱动加对某个新传感器（型号 LX123）的支持；③ 让已有驱动多认一个 media bus 格式宏 MEDIA_BUS_FMT_RGB888_1X24；④ 给某个桥接驱动实现 atomic_check 回调。
💡 显示答案
参考（仿写示范，非真实标题）：① rust: Add dma::Buffer —— 加一个对象，Add 后直接跟名字，不用 support；② media: i2c: Add LX123 image sensor driver —— 新驱动用 Add <型号> driver；③ media: foo: add support for MEDIA_BUS_FMT_RGB888_1X24 —— 细到一个宏时用 add support for + 宏名原样；④ drm/bridge: bar: Add atomic_check bridge_funcs callback —— 加一个具名回调，把所属 ops 结构体写出来。四条的共同点：①②是「加对象」，③是「加一个值」，④是「加一个实现」——粒度不同，support/for 的有无也就不同。
📖 原文：media: i2c: Add GC8034 image sensor driver / media: imx-mipi-csis: add support for MEDIA_BUS_FMT_YUYV8_1X16 / media: mt9v032: Add get_mbus_config subdev_pad_ops callback
📎 原文引用

每日一句：The noun you add decides the shape of the title — an object needs no support, a capability does.

仿写示范