Daniel P. Berrangé <[email protected]> writes: > On Wed, Jul 01, 2026 at 08:32:06AM +0200, Markus Armbruster wrote: >> [email protected] writes: >> >> >> The default monitor is usually a long lived object that will exist for >> >> the entire lifetime of the VM. A monitor can only service a single >> >> client at a time though, and so it might be desirable to hotplug >> >> additional monitors at runtime for specific tasks. If doing that, >> >> however, there is a need to remove the monitor when it is no longer >> >> needed. >> >> Whatever adds the additional monitor can also delete it. The fact that >> you propose other means suggests you believe this would be cumbersome in >> practice. Why? > > The use is is that someone/something wants to spawn a script that > does some job with the QEMU monitor. The thing that spawns the > script adds the new monitor and launches the script. Having > auto-delete means that you do not need to then keep track of that > script to perform cleanup of the dynamically added monitor. It > gives you "do the right thing" behaviour automatically when the > script exits, closing its monitor connection. > > The initial series proposed by Christian supported the ability > to run "object-del' on the monitor itself - a "self delete" > essentially. That is very awkward from the code POV, as it > required special case hanlding to ensure the QMP response to > the delete action got sent on the socket before the delete > action took place. It also made it impossible to then delete > the character device. > > Auto-delete gives us a better solution with less code complexity.
I agree "self delete" is problematic. I wonder how important the ability to fire and forget a script with a dedicated monitor is. I'd (naively?) expect whatever spawns the script to reap its exit status. If it is important, what about fire and forget a script with a dedicated character device? Can't come up with a use case for that within ten seconds. However, we use character devices for all kinds of crap. Food for thought, not a demand. >> >> Allowing a client to run "object-del" against its own monitor adds >> >> complex edge cases, as it would be desirable to send the QMP response >> >> despite the monitor sending it being deleted. Doing "object-del" alone >> >> will also result in orphaning a character device backend instance, as >> >> there is no opportunity to run the companion "chardev-del" command. >> >> >> >> A simpler way to ensure cleanup is to add the concept of auto-deleting >> >> monitor objects. Specifically when the "CHR_EVENT_CLOSED" event is >> >> emitted, the equivalent of "object-del" + "chardev-del" can be run >> >> internally. Since the transient client has already droppped its >> >> monitor connection, there is no synchronization to be concerned about. >> >> If object-del or chardev-del fail, there's no way to report the error. >> Can they fail? > > object-del can fail if > > * An object with the specified "id" does not exist. That shouldn't > happen in this case but harmless if it odes. > * object_del command tries to delete the monitor that > is servicing the object_del command. Cannot happen with > auto-delete > * the monitor has not finished initializing it BH with > chardev handlers. Cannot happen if we know we have a > live connection already. > > chardev-del can fail if > > * The chardev with "id" does not exist. SHouldn't happen > but is harmless if it does > * The chardev reports it is "busy" - aka the frontend > is still connected - we just deleted it so cannot happen > * Record/replay is in use - a niche use case > > So I don't think errors are a problem. > >> Do we always want to delete both monitor and character device? > > IMHO yes they are a pair whose lifetime should be tied together > for normal use. Would we make monitor auto-delete delete its character device if character devices also had an auto-delete feature? [...]
