Daniel P. Berrangé <berrange@redhat.com> writes:
Conceptually -object and object_add/object_del should be sufficient for essentially all QEMU configuration....if only we ported all our internal custom backends/devices/etc to QOM. That is of course a big job which is why it hasn't happened.
This series started with the premise that the monitor is one of the easier areas to convert since we have no more than three classes, a common base, and QMP and HMP subclasses[1]. So why not give it a go and thus unlock the ability to dynamically create/delete monitors in QMP/HMP.
This series does the conversion in a great many small steps to better understand the implications at each stage.
The high level outcome of this series is
* HMP and QMP monitors are QOM objects, 'monitor-hmp' and 'monitor-qmp' respectively
* Both can be cold plugged and hot plugged. QMP only, can also be hot unplugged.
* '-mon' is obsolete, deprecated and replaced by '-object', but -monitor, -qmp and kept as high level syntax sugar
Possible additional work: change monitor_parse() to build a MonitorOptions instead of a QemuOpts, so it call monitor_new() directly instead of via monitor_new_opts(). Observation, not a demand.
* QMP gains a concept of "close-action" which makes it possible to mark a monitor for auto-delete.
I'm not quite convinced this is warranted. I'd like to hear more about use cases. Is libvirt going to make use of it?
The monitor hot-unplug code and the qtest and functional testing code is heavily derived from a series sent by Christian Brauner which proposed new monitor_add/monitor_del commands:
https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html
I left Christian's authorship & SoB on the patches which were derived from his code, though the code has been refactored quite a bit in places, so bugs are quite possibly my own.
Note that Christian's series allowed the use of "monitor_del" commands against the current monitor session. ie a client could delete the very monitor it was using. This is an awkward concept as it needs special casing to delay the deletion to happen in the background, such that that the QMP response to 'monitor_del' could still be sent back. This also left the chardev was orphaned as there's no way to run 'chardev_dev' in that usage pattern.
To provide an alternative mechanism to address the same use case, this series introduces the 'close-action' concept mentioned above, that allows hotplugging a monitor to service a specific task, with the monitor being purged when the script closes its connection. This avoids the special casing that an explicit "self deletion" paradigm required.
While supporting hotplug of HMP was trivial, I didn't do any work to think about hotunplug of HMP, since IMHO it is of limited value given HMP's typical use cases.
[1] ~~~ we did all this not because it was easy, but because we thought it would be easy ~~~
Heh! Fully addressing all review comments before the soft freeze may or may not be possible. Perhaps punting sufficiently harmless changes to a post-freeze fixup series could help. Use your judgement. We could also leave the close-action feature for the next development cycle.