Thomas Huth <th...@redhat.com> writes: > On 28/03/2023 07.26, Markus Armbruster wrote: >> Paolo Bonzini <pbonz...@redhat.com> writes: >> >>> I am honestly not a fan of adding a more complex option,.just because >>> query-command-line-options only returns the square holes whereas here we >>> got a round one. >>> >>> Can we imagine another functionality that would be added to -teardown? If >>> not, it's not a good design. If it works, I would add a completely dummy >>> (no suboptions) group "async-teardown" and not modify the parsing at all. >> >> Does v2 implement your suggestion? >> Message-Id: <20230320131648.61728-1-imbre...@linux.ibm.com> >> >> I dislike it, because it makes query-command-line-options claim >> -async-teardown has an option argument with unknown keys, which is >> plainly wrong, and must be treated as a special case. Worse, a new kind >> of special case. > > I agree with Markus, it sounds like a bad idea to create a new special case > for this. > > Paolo, what do you think of my "-run-with" suggestion here: > > > https://lore.kernel.org/qemu-devel/3237c289-b8c2-6ea2-8bfb-7eeed637e...@redhat.com/ > > I still think that this is a good idea, even if it is a "grab-bag" as Markus > said, it would give us a place where we could wire future similar options, > too, without running into this problem here again and again. > >> Can we have a QMP command, so libvirt can use query-qmp-schema? > > Question is whether this could be toggled during runtime...? Or did you mean > a command that just queries the setting of the option, e.g. > "query-async-teardown" which then reports whether it is enabled or not?
Mildly ugly, as the command is pretty much useless except as a witness for the CLI option. We've done this before. >> In case QMP becomes functional too late for the command to actually >> work: make it always fail for now. It can still serve as a witness for >> -async-teardown. If we rework QEMU startup so that QMP can do >> everything the CLI can do, we'll make the QMP command work. > > Adding non-working functions sounds ugly... Non-working functions that could totally work with QEMU startup reworked are only mildly ugly, I think. > Anyway, we're slowly running out of time for QEMU 8.0 ... if we can't find an > easy solution, I think we should rather postpone this to the next cycle > instead of rushing unfinished stuff now. Yes. I think we can still do it if we agree quickly on which kind of ugly we hate the least. Adding -async-teardown as a stable interface was premature. We should have marked it unstable when no libvirt patch was ready when we cut QEMU 7.2. Adding new external interfaces is still not hard enough :)