On Wed, Jul 01, 2026 at 03:41:26PM +0200, Markus Armbruster wrote: > 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?
Sure, it fits in the commit message for the auto-delete patch. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
