[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [PATCH] vl, qemu-config: remove -set
Date: Thu, 12 Nov 2020 07:55:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

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"?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]