今日重点：💬 地道表达——正式补丁 prose 教你怎么写，而评审往来才是内核社区的日常口语。今天拆一段真实评审（lkml · KVM TDX CPUID 补丁讨论），学怎么「客客气气地表达不同意」。
💬 地道表达：一段真实评审对话
/ section★ 客套与肯定：Thanks, it reads better.
真实原句 Thanks, it reads better.
中文理解 「谢谢，这样读起来顺多了。」—— 作者改了代码后，评审人的简短认可。it reads better 是内核社区夸「这段代码/这段描述改得更顺」的惯用说法，比 good 更具体（强调「读感」而非「正确」）。
用法 回复别人的修改时用
reads better：The new comment reads better. / This version reads much better than the previous one. 简短、具体、有温度——比一句干巴巴的 OK 更像真人评审。 🔗 原文
★ 委婉否定：I think ... is not necessary, we can rely on ...
真实原句 I think 1) is not necessary, we can rely on 2).
中文理解 「我觉得第 1) 条没必要，我们依赖 2) 就够了。」—— 内核评审里提「删掉某步」的标准温和说法：用
I think 开头（主观、非命令），用 we can rely on 给出替代（「我们」把作者拉进同一立场）。 用法 想建议删功能/去代码时：
I think this check is not necessary, we can rely on the existing error path. 比 Remove this 柔和得多——把决定权留给作者，自己只给理由。 🔗 原文
★ 评审人交代自己的取舍习惯：In general, I prefer not to ...
真实原句 In general, if a feature is not supported by the common KVM CPU caps, I prefer not to add it to the list to save a few lines of code, which probably is dead code.
中文理解 「总的来说，如果某特性不被通用的 KVM CPU caps 支持，我倾向不把它加进列表——省那几行八成是死代码的代码。」——
In general 起手表明这是「一贯原则」而非针对本条；I prefer not to 是「我倾向不」而非「你不许」；末尾 which probably is dead code 轻描淡写补一刀，点破那几行没用。 用法 给维护者写理由时：
In general, I prefer not to add code paths that are never exercised — they tend to rot. 用 prefer 而不是 must/should，姿态是「这是我的取舍」，不是「你必须照做」。 🔗 原文
★ 作者接话：I can call this out in the changelog
真实原句 I can call this out in the changelog, and maybe also the doc for KVM_TDX_CAPABILITIES.
中文理解 「我会在 changelog 里点明这一点，可能也在 KVM_TDX_CAPABILITIES 的文档里提一下。」—— 作者回应评审意见的标准姿态：
call this out（明确指出/点名），用 I can 而不是 I will，语气更谦和（「我可以」而非「我保证」）。 用法 答应把某个说明写进文档/注释：
I can call this out in the commit message and the header comment. I can + 具体动作，是「愿意配合」又不显得卑微的平衡点。 🔗 原文
✨ 辅助彩蛋（阅读）
/ section★ 把四句串起来看：一场评审的「温度曲线」
串读 先夸（
reads better）→ 再提取舍（I think ... not necessary）→ 交代原则（In general, I prefer not to...）→ 作者接招（I can call this out...）。注意：没有一句是祈使句命令，全是「观点 + 理由 + 给作者留余地」—— 这就是内核评审的语感：把要求说成建议，把否定包在肯定里。 可学点 下次在群里/评审里想表达不同意，试试这套：先用
reads better / looks reasonable 接住对方，再用 I think ... not necessary 或 I'd prefer ... 给出你的取舍，最后一定补理由——内核社区不流行生硬的 No。 🔗 原文
✍️ 今日练习
/ section✍️ 用今天学的表达，给一个假设的补丁回复写 3 句英文：① 肯定一处改进（reads better）；② 委婉说某一步没必要（I think ... not necessary, we can rely on ...）；③ 交代你的一贯原则（In general, I prefer not to ...）。
💡 显示答案
参考（仿写示范，非原句）：The simplified error path reads much better now. I think the extra validation step is not necessary here — we can rely on the existing bounds check. In general, I prefer not to add checks that the callers can't actually hit; they tend to become dead code.
📖 原文：In general, if a feature is not supported by the common KVM CPU caps, I prefer not to add it to the list to save a few lines of code, which probably is dead code.
📎 原文引用 Kernel review is politeness with a kernel beneath it — disagree as a suggestion, not a command.
内核英语 · 每日一篇
💬 评论
使用 GitHub 账号登录即可留言