关于qemu的二三事（3）————如何给qemu打patch

关注

原创最新推荐文章于 2026-04-22 04:50:19 发布 2.1k 阅读 AI 写同款· GEO 优化 ›

AFL QEMU模式安装报错（afl-2.52b & qemu-2.10.0）[已解决] 搭建afl-qemu模块的时候，碰到了如下报错： /opt/AFL/qemu_mode/qemu-2.10.0/linux-user/ioctls.h:174:9: error: ‘SIOCGSTAMPNS’ undeclared here (not in a function); did you mean ‘SIOCGSTAMP_OLD’? 174 | IOCTL(SIOCGSTAMPNS, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timespec))) | ^~~~~~~~~~~~ 阅读详情

其实这篇文章应该放在这个系列的后面说比较合适，但是考虑到下面要展开的关于qemu源码分析的内容比较耗时间，所以就先把不那么耗时间的文章先写出来。

标题这里所说的打patch，是指把代码推送到qemu社区。

我们知道，在github上边是有qemu的主页的，qemu下边有一堆项目，不仅仅是qemu，还有ipxe、u-boot、seabios啊一堆很牛逼的项目。

那我们在 qemu/qemu 点进去，首当其冲看到这么一句话：

Official QEMU mirror. Please see http://wiki.qemu.org/Contribute/SubmitAPatch for how to submit changes to QEMU. Pull Requests are ignored.http://www.qemu.org

意思就是说，在github上边这个页面只是个mirror，给你下代码玩的，想提交patch，您还是仔细看看wiki，按照老规矩我们发到社区里面maillist讨论吧。这个github页面不接受您任何pull request，您看看，惊不惊喜？刺不刺激？开不开心？哈哈哈

言归正传，我们还是来说说怎么把patch发到社区并讨论吧。

上边提到了一个链接，里面很详细的指出了发patch要经过怎么样的流程，我来简单总结一下，主要内容其实还是来自于这个wiki：

首先呢你要用 git format-patch 把patchfile弄好，然后按照下面的来：

1，写patch，要注意以下几个方面

1）codestyle的问题，qemu提供了一个检查工具，在源码目录的 .script/checkpatch.pl,

跑一下 checkpatch.pl <patchfile>，会有代码检查结果的提示，代码不规范的同学们自求多福吧。

2）你的patch最好针对的是master而不是其他的branch；

3）如果代码太多，最好分成几个patchfile；

4）要发有用的patch，那种formatting啊codestyle啊whitespace啊什么乱七八糟的玩意儿无卵用就不要专门发patch来哔哔了；

5）commit log要简洁有力清晰；

2，patch提交，

简单来说，就是要用git -sendmail来发patchfile，要CC给相应源码的maintainer

1）该把patch发给哪个maintainer？

qemu提供了一个脚本来让你知道， ./scripts/get_maintainer.pl

比如说，你给cpus.c 这个文件打patch，你就跑一下
./scripts/get_maintainer.pl -f cpus.c
然后你就看到：
[root@localhost qemu]# ./scripts/get_maintainer.pl -f cpus.c
Paolo Bonzini <pbonzini@redhat.com> (maintainer:Overall)
Peter Crosthwaite <crosthwaite.peter@gmail.com> (maintainer:Overall)
Richard Henderson <rth@twiddle.net> (maintainer:Overall)
qemu-devel@nongnu.org (open list:Overall)
上边就列出了相关源码或者说feature的maintainer的邮箱，发patch的时候需要CC给他们。

2）不要以附件的形式发patch；

3）要用git sendmail发patch；

发之前可以先编辑一下cover-letter，介绍和解释一下patch的内容、原因，

4）patch的邮件里面要有"From:" and "Signed-off-by:"

5）发送一个包含有多个patchfile的patch时，要写cover-letter解释介绍你的patch作用和目的；

6）如果有必要，请加上RFC的标记，

比如"[PATCH RFC v2]"，使用git format-patch --subject-prefix=RFC可以帮你搞定

RFC，即request for comments

3，参与code review

1）要解决code review中发现的问题；

不是patch发出来就万事大吉，社区讨论的时候可能会发现你的一些bug和问题，

要持续跟进和解决，解决之后要发出新版本的patch；

2）社区讨论的时候会给你的patch加上comments，要保持关注；

一般来说，这些人都是资深的工程师和大牛，很多人都是一针见血，

而且人家百忙之中review你的patch，你得回报以尊重。

3）修改后的patch再发的时候要加上版本标记，比如V2、V3。。。。

4）在后续版本的patch需要给指出与上个版本的不同，一般来说git formatpatch做的很完善了；

4，小技巧

1）review了别人的patch，写comments的时候最好加上Reviewed-by的标记；

2）如果patch发出去之后没有回应，一两周之后可以发一个ping的邮件催一催；

3）你的patch如果经过充分讨论之后，maintainer会帮你发pull request到master，你可能需要rebase或者解决conflict；

4）没事多去review别人的patch，给社区多做贡献，哈哈哈

说一点我自己的体会：

古龙说，有人的地方就有江湖。开源社区也不例外，你若是大牛，你发出的patch很快就有人回应；你是无名之辈，你的patch如果不是那种石破天惊的，很可能不多久就泯然众人矣。我自己就是个例子，发了一个vcpu-pin的patch，来直接设定qemu里面虚拟机的cpu affinity，结果没人鸟，泯然众人矣。

我自己发到自己的github上了，欢迎大家探讨。如果觉得对于自己的项目有用，欢迎拿去用。

地址附上： https://github.com/BenyuXu/qemu/pull/1