[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 1/1] util/async-teardown: wire up query-command-line-optio
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v5 1/1] util/async-teardown: wire up query-command-line-options |
Date: |
Tue, 28 Mar 2023 09:57:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Thomas Huth <thuth@redhat.com> writes:
> 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?
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 :)