From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org, Vincent Palatin <vpalatin@chromium.org>
Subject: Re: [Qemu-devel] [PATCH] Deprecate '-enable-kvm' and '-enable-hax' in favour of '-accel'
Date: Tue, 02 May 2017 17:01:28 +0200 [thread overview]
Message-ID: <87pofrfgl3.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <ac13fd46-bd6e-6a8a-2c72-cc8d683d5026@redhat.com> (Paolo Bonzini's message of "Tue, 2 May 2017 15:22:22 +0200")
Paolo Bonzini <pbonzini@redhat.com> writes:
> On 02/05/2017 12:48, Christian Borntraeger wrote:
>>> 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. 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. So my preferred variant
>> is
>
> Even for Linux the rules aren't 100% black or white. There have been
> cases where small breakage are introduced, for example 4.12 will break
> the BLKDISCARDZEROES ioctl.
>
> We shouldn't treat things are black or white here too.
>
> "-usbdevice" makes sense to deprecate because it brings together a
> complicated parsing mechanism, though perhaps we could keep it for
> simple devices such as keyboard, mouse, tablet where it's pretty surely
> in use in the wild.
>
> "-drive cyls=..." also makes sense to deprecate because it is a very
> obscure functionality.
>
> "-drive serial=..." would be nice to deprecate, but I think it's already
> less clear that it's not in use in the wild. Probably it's still on the
> side of wanting to eventually remove it.
>
> "-net" is more complicated still. It's almost surely in use in the
> wild, but then probably the users are fairly advanced and (with the
> provision that documentation should be updated) I guess we could
> eventually get there.
>
> But I really, really see no point in removing --enable-kvm. It costs
> perhaps 10 lines of code that has pretty much no ramifications elsewhere
> in the code. If anything I'd expect "-machine accel" to disappear
> before, if ever (in favor of multiple "-accel" options, e.g. "-machine
> accel=kvm:tcg" can become "-accel kvm -accel tcg".
I basically agree, except I wouldn't say "no point", but "doesn't buy us
enough to justify inconveniencing users".
What we've done before for options that have become unloved, but not
harmful, is remove them just from documentation. Grep qemu-options.hx
for "HXCOMM Deprecated". Let's do that for --enable-kvm and similarly
weird sugared options.
next prev parent reply other threads:[~2017-05-02 15:01 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
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 [this message]
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=87pofrfgl3.fsf@dusky.pond.sub.org \
--to=armbru@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.