From: "Daniel P. Berrange" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Vincent Palatin <vpalatin@chromium.org>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Deprecate '-enable-kvm' and '-enable-hax' in favour of '-accel'
Date: Tue, 2 May 2017 13:16:33 +0100 [thread overview]
Message-ID: <20170502121633.GK3459@redhat.com> (raw)
In-Reply-To: <69beede1-b218-2e8f-e2b7-b8225cf75a87@redhat.com>
On Tue, May 02, 2017 at 02:07:15PM +0200, Thomas Huth wrote:
> On 02.05.2017 13:59, Daniel P. Berrange wrote:
> > On Tue, May 02, 2017 at 01:26:17PM +0200, Thomas Huth wrote:
> >> On 02.05.2017 12:48, Christian Borntraeger wrote:
> >>> On 05/02/2017 12:37 PM, Thomas Huth wrote:
> >>>> On 02.05.2017 12:32, Christian Borntraeger wrote:
> >>>>> On 05/02/2017 12:06 PM, Thomas Huth wrote:
> >>>>>> The '-enable-...' option do not make too much sense: They do not
> >>>>>> allow additional parameters, using '-accel xxx' is shorter than
> >>>>>> '-enable-xxx' and we're also inconsistent here, since there is
> >>>>>> no '-enable-xen' option available. So let's try to convince the
> >>>>>> users to use '-accel xxx' instead.
> >>>>>
> >>>>> google has 36000 hits for "--enable-kvm" and 18000 hits for "--accel kvm"
> >>>>> So I assume this will affect a lot of setups for only a very small benefit.
> >>>>
> >>>> I'm aware of the fact that likely a lot of users are still using
> >>>> -enable-kvm, and I did not mean that we should remove it soon yet. But
> >>>> IMHO we should start now to inform the users that they should slowly
> >>>> switch to the better option "-accel" instead, so that we could maybe
> >>>> remove this "-enable-xxx" stuff sometime in the distant future (let's
> >>>> say QEMU v4.0?).
> >>>
> >>> I come from the Linux side, where "breaking a working setup" will result in
> >>> an angry Linus.
> >>
> >> IMHO that's a good approach, but I think it should primarily applied for
> >> the interfaces that are designed as "API" to other software layers, i.e.
> >> things like QMP and the "-machine" parameter.
> >> "-enable-kvm" is in my eyes rather a "syntactic sugar" convenience
> >> option, so I'd not apply this rule to this option.
> >>
> >>> We certainly have not such strict rules here and we could
> >>> base the decision on the question "how expensive is the maintenance
> >>> of this option?". I think marking it as "legacy option" is fine, but I doubt
> >>> that removing it will make qemu maintenance cheaper.
> >>
> >> Likely not. Actually, I have another point of view in mind here: You
> >> have to consider that QEMU has a *lot* of options, and I think this is
> >> very confusing for the users, especially the new ones. If we always
> >> provide two or three ways to achieve a goal, especially in an
> >> inconsistent way like we do it here, we likely rather create frustration
> >> than joy for the normal users. Providing a clean, straightforward CLI
> >> interface one day could help to improve the user experience quite a bit.
> >
> > The issue is that we have mutually exclusive requirements here. For a
> > straightforward, easy to understand CLI, things like "--enable-kvm" are
> > much quicker to discover & understand than "-machine accel=kvm". The
> > latter gives much more flexibility since it can set all the other opts,
> > but most of those are rarely used by people who are invoking QEMU
> > manually/directly. We need the things like -machine for libvirt and
> > similar, but they are not end user friendly. Killing all the shortcuts
> > like --enable-kvm would cut down the args we expose, but forcing users
> > onto more complex syntax for args like -machine is not improving their
> > lives in general if they don't need that extra flexibility.
>
> Theoretically yes, but in this case we also have the "-accel kvm" option
> which is IMHO also straighforward and easy to understand, and even
> shorter than "-enable-kvm". If you look at my patch, I did *not* want to
> force the normal users to use "-machine accel=kvm" here, so I don't see
> the point of your argument here.
Just looking at the -help output though we have
"-machine [type=]name[,prop[=value][,...]]
property accel=accel1[:accel2[:...]] selects accelerator
supported accelerators are kvm, xen, tcg (default: tcg)"
and
"-enable-kvm enable KVM full virtualization support"
but the "-accel" option is not documented, so essentially doesn't exist,
unless you read the man page to see if there are other secret options
listed there. So from -help output, "-enable-kvm" looks like the best
option to pick from a novice user POV.
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 :|
next prev parent reply other threads:[~2017-05-02 12:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-02 10:06 [Qemu-devel] [PATCH] Deprecate '-enable-kvm' and '-enable-hax' in favour of '-accel' Thomas Huth
2017-05-02 10:21 ` Daniel P. Berrange
2017-05-02 10:29 ` Thomas Huth
2017-05-02 10:32 ` Christian Borntraeger
2017-05-02 10:37 ` Thomas Huth
2017-05-02 10:48 ` Christian Borntraeger
2017-05-02 11:26 ` Thomas Huth
2017-05-02 11:59 ` Daniel P. Berrange
2017-05-02 12:07 ` Thomas Huth
2017-05-02 12:14 ` Thomas Huth
2017-05-02 12:16 ` Daniel P. Berrange [this message]
2017-05-02 12:38 ` Daniel P. Berrange
2017-05-02 12:46 ` Thomas Huth
2017-05-02 13:22 ` Paolo Bonzini
2017-05-02 15:01 ` Markus Armbruster
2017-05-02 15:09 ` Paolo Bonzini
2017-05-02 15:53 ` Thomas Huth
2017-05-02 16:08 ` Paolo Bonzini
2017-05-02 16:19 ` Thomas Huth
2017-05-02 16:22 ` Paolo Bonzini
2017-05-03 8:07 ` Markus Armbruster
2017-05-02 12:21 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170502121633.GK3459@redhat.com \
--to=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=vpalatin@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.