Re: [PULL 31/31] qemu-option: warn for short-form boolean options

[Daniel P . Berrangé]

On Tue, Feb 16, 2021 at 01:36:46PM +0000, Peter Maydell wrote:
> On Tue, 16 Feb 2021 at 13:30, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 16/02/21 12:58, Peter Maydell wrote:
> > > On Tue, 16 Feb 2021 at 11:23, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > >> I agree, and that's why I have no plans to move -chardev off QemuOpts;
> > >> warning is a different step than excising and sometimes years pass from
> > >> one to the other.  However, that doesn't prevent introducing a warning
> > >> so that users slowly move away from the problematic functionality.
> > >
> > > If we want to continue to support the functionality then complaining
> > > about it doesn't serve much purpose IMHO.
> >
> > It depends.  I don't want to support it forever for all options;
> > -machine, -accel and -object are those for which I do intend to remove
> > support for short-form options after the two release deprecation period.
> >
> > My first submission of this patch even special cased "-chardev" to hide
> > the warning, but this was dropped in response to reviews.
> > (https://patchew.org/QEMU/20201103151452.416784-1-pbonzini@redhat.com/20201103151452.416784-5-pbonzini@redhat.com/).
> >   I can add that back if you prefer, since it's very simple.
> 
> I agree with Daniel that it would be better to be consistent about
> whether we like these short options or not, but disagree that
> the answer is to deprecate everywhere :-)
> 
> Broadly, I think that being able to say 'foo' when foo is a
> boolean option being set to true is obvious and nice-to-use
> syntax, and I don't really want it to go away. 'nofoo' for
> 'foo=false' is much less obvious and I'm happy if we only
> support it as a special-case for 'nowait'.

There's an inherant tension in our goals here.

It is widely thought that QEMU configuration is complex and painful to
understand. From my POV a big part of that believe comes from the fact
that we have so many inconsistencies in our parsing code, and many ways
of doing the same thing.

Every time we have special cases like  "foo" as a short hand for "foo=on"
or "nofoo" as a short hand for "foo=off",  we increase the complexity of
QEMU and that impacts how our users view QEMU. 

IMHO we'd be better off eliminating the boolean short forms entirely
in all QEMU options, so that we get consistency and a clearer right way
of doing things. The short bool format was created with good intentions,
but on balance a bare "foo" isn't a big enough win over "foo=on" to
justify its existance long term.

I do agree though, that we should not be deprecating something if our
documentation is still showing people the deprecated syntax, as that
makes us look even worse.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|