Hello,
Currently, qemu plugin support only works in Linux and I would like to get qemu
plugins working on
Windows. I have had some success experimenting with this locally (based on some
previous work by
Yonggang Luo, see below), but would like to gauge opinion before I commit to
suggesting a solution.
The overall structure of how plugins work is this:
1. qemu executable loads plugin.so.
2. plugin.so defines a function qemu_plugin_install, which qemu looks up, and
calls.
during that function call plugin.so might call some of the qemu_plugin_*
functions that the host
executable has implementations of. plugin.so is compiled with unresolved
references to these functions,
and they get linked up at dll load time.
Windows doesn't let you do such on-the-fly load time linking. You need a dll
import library, which is
specific to a particular host executable. The qemu project, however, has many
executables, any
of which might want to load a given plugin.
Possible ways to get things working on Windows:
1. Make the dll import library. Possibly refactor the qemu plugin code into a
single qemu_plugin.{so,dll},
and then make the import library for that. I don't fully understand this
system, and I'm still concerned
it would be fragile (if qemu is recompiled, do I need to recompile all my
plugins against the new
version of the import library?)
2. Change the way plugins can access the available host API. We could define a
typedef struct full
of function pointers and have one of those passed to the plugin in
qemu_plugin_install. The plugin
can use this to populate some global variable, and use it to call the
necessary functions.
3. Have windows plugins export a bunch of qemu_plugin_* function pointers, and
have the plugin loader
code find all the pointers and point them at real functions. This has the
benefit (in some
simple cases) of not needing any code changes on the plugin side. However,
it means qemu-plugin.h
declares new symbols on the plugin side, and you have to be careful to only
declare them once in
the plugin.
Having real functions on linux and function pointers on windows is a neat
trick in C, but might
cause subtle differences for systems that automatically generate bindings
for other languages -
functions will always be set, but function pointers might be behind some
nullable type wrapper.
I'm inclined toward the second option as being the neatest, but it does involve
the most API churn
(though both styles could be maintained for some time, just only the newer
style would work on
windows).
Previously, some work was done to try and get windows plugins working in 2020:
[1], [2].
This work was never merged in. I have emailed the original author to try to
find out what happened
(and CCed them here). This work took the 3rd option from above - defining a set
of function pointers
in place of the linked up function declarations.
Does anyone have strong feelings about how to solve this?
[1]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg744980.html
[2]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg749982.html
Regards,
Greg Manning
--
Follow Rapita Systems on
LinkedIn<https://www.linkedin.com/company/rapita-systems?utm_source=rs_email_sig>
