On 12/21/21 16:40, Markus Armbruster wrote:
Paolo Bonzini <pbonz...@redhat.com> writes:

On 12/21/21 13:58, Markus Armbruster wrote:
Is this a regression?  I suspect commit 5dacda5167 "vl: Enable JSON
syntax for -device" (v6.2.0).

Obviously not a regression: everything that used to work still works.

FWIW I think -set should be deprecated.  I'm not aware of any
particularly useful use of it.  There are a couple in the QEMU tests
(in vhost-user-test and in qemu-iotests 068), but in both cases the
code would be easier to follow without; patches can be dusted off if
desired.

-set has its uses, but they're kind of obscure.  When you want to use
some canned configuration with slight modifications, then -readconfig
canned.cfg -set ... is nicer than editing a copy of canned.cfg.  For
what it's worth, we have a few cans in docs/config/, and we refer to at
least one of them in the manual (in docs/system/devices/usb.rst).

There are a few really good ideas in QemuOpts.  I count -readconfig,
-writeconfig and -set among them.  Unfortunately, they have been marred
by us not converting the whole CLI to QemuOpts as envisaged.  And now we
never will, because our needs have long outgrown what QemuOpts can
provide.

I'd love to have unmarred, QAPI-based replacements.  However, I doubt
maintaining backwards compatibility will be practical and worthwhile.

Declare these options unstable?


I agree.

Without QemuOpts, and more precisely the ability to alter them before they are really handled, this kind of feature will be impossible to have.

Only way I see, is to reverse the mechanism:
+ handle set option before, it store the key,value somewhere
+ an option like -device checks that store and fetch their values.

--
Damien


Reply via email to