linux-startup

在 Linux 内核开发（比如你之前了解的 KStackWatch、KFuzzTest 这些工具补丁）里，RFC 是 “Request for Comments” 的缩写，直译是“请求评论” ——简单说，就是开发者把自己的“想法草案、原型代码”提交到内核邮件列表（比如 linux-kernel@vger.kernel.org），目的是让社区里的其他开发者（维护者、架构师、有经验的开发者）帮忙看：这个设计合理吗？有漏洞吗？有没有更好的实现方式？

你可以把它理解成 “项目立项前的公开征求意见阶段” ，不是正式提交的可合并代码，核心是“收集反馈、完善设计”，而不是“要求立即合并到内核”。

举个和你相关的例子

比如之前聊的 KStackWatch 工具，它的补丁系列有个“RFC 版本”——这时候王锦超（开发者）并没有把它做成成熟的 v1、v2 版本，而是先把“用硬件断点+探针监控栈损坏”的核心思路、基础代码框架丢到社区，问大家：

• 这个工具解决的“栈崩溃与源头分离”问题，是不是内核里的真痛点？
• 用 kprobe+fprobe+硬件断点的组合，开销会不会太高？
• /proc/kstackwatch 这个配置接口，符合内核工具的设计规范吗？

等收集到社区的意见（比如“用 fprobe 替代 kretprobe 更轻量”“要支持 CPU 热插拔”）后，才会根据这些反馈修改代码，推出 v1、v2、v3… 直到社区觉得“设计合理、代码成熟”，才会被合并到 Linux 内核主线。

RFC 的核心特点（和正式补丁的区别）

维度	RFC 版本	正式补丁（v1、v2…）
目的	收集意见、验证思路	提交可合并的成熟代码
代码质量	原型级，可能有 bug、功能不完整	经过测试，bug 少、功能完善
社区态度	讨论为主，不会被合并	评审通过后，可能被合并到内核主线

简单总结：RFC 就是内核开发里的“公开头脑风暴”——先把想法抛出来让大家拍砖，改到大家都觉得靠谱了，再正式推进。