Re: [PATCH] vl, qemu-config: remove -set

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 11/11/20 16:03, Daniel P. Berrangé wrote:
>> On Wed, Nov 11, 2020 at 08:57:16AM -0500, Paolo Bonzini wrote:
>>> -set as far as I can see has basically no use.  It was intended as an 
>>> override
>>> mechanism for configuration files, but even configuration files themselves
>>> are hardly used.  Drop it with prejudice.
>>> 
>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>> ---
>>>  docs/system/deprecated.rst |  6 ++++++
>>>  include/qemu/config-file.h |  1 -
>>>  qemu-options.hx            |  9 ---------
>>>  softmmu/vl.c               |  4 ----
>>>  util/qemu-config.c         | 33 ---------------------------------
>>>  5 files changed, 6 insertions(+), 47 deletions(-)
>>
>> iotest 068 uses -set and qtest vhost-user-text.c also does
>> IOW, it looks like it is valid to use -set, even if you're not using
>> -readconfig.

Of course that's valid.

>> Libvirt doesn't use -set, but we've had users who make use of
>> libvirt
>> command line passthrough for QEMU with -set.
>
> Hmm, indeed:
>
> https://patchwork.kernel.org/project/qemu-devel/patch/20181218041625.24969-16-mst@redhat.com/

Such monkey-patching may not be wise, but unwise != invalid.

>> IOW, I'm not convinced real world usage is near zero as suggested.

Guessing the gamut of usage out there in the real world correctly is
always a tall order :)

> Yes, perhaps it's not. :)  Though for both tests you pointed out it's
> even cleaner not to use it, there seems to be real world usage at
> least with "device".

I have common test configurations files for -readconfig.  I've used -set
for quick monkey-patching once in a great while.  Now, such ad hoc use
is a *weak* argument against ditching the feature.  But it does
undermine the "basically no use" proposition.

> It is probably more viable to deprecate or even forbid usage of "-set"
> with anything but "device".  vhost-user-test.c would still be
> affected, but it's a relatively small patch.

Deprecating only some uses buys us next to nothing, I think.  If we want
to deprecate it, just deprecate it.

Immediate removal of -set / rejection of -set for some option groups
needs more justification than just "I think we can get away with it":
there has to be a tangible benefit.  What would immediate removal buy us
over the orthodox "deprecate, wait for grace period to expire, remove"?