|
From: | Thomas Huth |
Subject: | Re: [PATCH v5 1/1] util/async-teardown: wire up query-command-line-options |
Date: | Tue, 28 Mar 2023 09:20:06 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 |
On 28/03/2023 07.26, Markus Armbruster wrote:
Paolo Bonzini <pbonzini@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-imbrenda@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: 3237c289-b8c2-6ea2-8bfb-7eeed637efc7@redhat.com/">https://lore.kernel.org/qemu-devel/3237c289-b8c2-6ea2-8bfb-7eeed637efc7@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?
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... 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.
Thomas
[Prev in Thread] | Current Thread | [Next in Thread] |