On 1/16/26 4:35 AM, Daniel P. Berrangé wrote:
On Fri, Jan 02, 2026 at 01:47:13PM -0800, Pierrick Bouvier wrote:
Writing plugins in C can be sometimes tedious, especially when using Glib to
keep track of execution state. We can directly use the same C API but write our
plugin in C++, benefiting from its great standard library offering strings,
smart pointers, data structures and synchronization mechanisms.
It's common for downstream QEMU forks to provide C++ for plugins, like this:
- https://github.com/panda-re/panda/tree/dev/panda/plugins
- https://github.com/FlorentRevest/DejaView/tree/main/src/qemu_plugin
Hopefully this will help more people to use upstream QEMU, and as a benefit, get
their contribution back and help to develop plugins ecosystem upstream directly.
This series first cleans up build system for plugins, factorizing details
between contrib/plugins and tests/tcg/plugins folders.
Then, we perform codebase cleanups to fix conflicts between existing headers
and C++ headers.
After that, we can update the C++ standard used by QEMU, to benefit fully
from latest updates of the language.
Finally, we define an empty C++ plugin, making sure we can keep track of
possible regression in qemu-plugin header.
Note: This series is *not* a trojan horse to bring C++ in QEMU
codebase, nor to define an alternative C++ API for plugins. It's just enabling
more users to get the most out of existing C plugin API.
That's somewhat misleading, because as the diffstat below shows,
this is indeed bringing new C++ source files into QEMU:
contrib/plugins/cpp.cpp | 119 ++++++++++++++++++++
and the description above talks about bringing more C++ plugins in
from external forks, and the meson.build files are modified to
deal with C++.
I personally would not mind having other C++ plugins, as it would invite
people who contribute to downstream forks to contribute to upstream QEMU
instead, which may include new useful API also!
Those files will be conditioned by the presence of a C++ compiler, so
there is no impact for the people who don't want to deal with it, nor
build it.
It does not open any door to introduce C++ anywhere else.
We've had a handful of C++ files historically we've worked to
reduce, with the eventual goal of not using a C++ toolchain for
any part of QEMU build. Given that IMHO qemu.git should not be
adding new C++ sources files, even if in the plugins dir.
The series does not force having a C++ compiler installed, the plugin
compilation is entirely optional, so no change for existing users or CI
images.
With that, we still need to have at least one C++ file in to test if it
works. In case there is nothing checked in, there will be regression.
We are luckily catching things in CI because clang++ is there in some
images, so it will trigger an error as expected if something is introduced.
Most of the QEMU downstream forks have C++ plugins, because it's just
way more convenient.
Since the qemu-plugin.h file should be entirely self-contained,
do we actually need to be bundling all the plugins into qemu.git ?
Should we in fact have a sepate gitlab.com/qemu/qemu-plugins repository
where we keep plugins ?
2 years ago, contrib/plugins were simply sitting in their directory
without being built. As a result, they were broken when I tried to
compile them. So we added them as part of a normal build, and it solved
our problems.
Pushing things in another repository is exactly the opposite of that
direction.
It's not because you personally don't like or use a feature that it
should be in its own repository. Please kindly consider that other
people have different needs or opinions than you.
Since the qemu-plugin.h file is defining a somewhat stable API, plugins
in that separate repo ought to be able to build against multiple QEMU
releases, and could thus benefit from not being bundled together and
don't need to be on the same release cycle.
API is versioned but not officially stable. We may have breaking
changes, like renaming/removal of existing functions.
The main qemu.git CI jobs could trigger testing of a separate
qemu-plugins.git repo, so we still validate no regressions.
I'm not sure what is the point of breaking down things to tie them in
CI. What will happen when there is a breaking change? You now have two
broken repositories instead of a single one to fix.
With regards,
Daniel
