Daniel P. Berrangé <[email protected]> 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.
