Daniel P. Berrangé <[email protected]> writes: > On Wed, Jul 01, 2026 at 09:52:44AM +0200, Markus Armbruster wrote: >> 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. > > Replied about that inline to the patch. IMHO without this facility > the series does not fully address the needs of systemd that motivated > the original patches: > > https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html > >> Is libvirt going to make use of it? > > This wasn't motivated by libvirt's needs, but indeed it could be > useful for libvirt. Currently if apps want to access QMP, they > need to use libvirt's QMP passthrough, which means they need > special client code to talk to libvirt APIs. > > With this libvirt could dynamically add a monitor, with auto > close, open it and pass the open FD back to the client app. > libvirt would not need to watch for when the client app is > gone as dropping the FD would cleanup the monitor.
Alright, that's fair. The management application doesn't spawn something that wants a dedicated monitor, it makes one for a client. Would this fit into a commit message somewhere? [...]
