qemu-trivial
[Top][All Lists]
Advanced

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

Re: [Qemu-trivial] [Qemu-devel] [RFC PATCH 4/4] qemu-options: Do not sho


From: Thomas Huth
Subject: Re: [Qemu-trivial] [Qemu-devel] [RFC PATCH 4/4] qemu-options: Do not show -enable-kvm and -enable-hax in the docs anymore
Date: Wed, 13 Jun 2018 17:44:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 13.06.2018 17:19, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 05:11:51PM +0200, Thomas Huth wrote:
>> On 13.06.2018 15:44, Daniel P. Berrangé wrote:
>>> On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
>>>> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
>>>>> We've got three ways of enabling an accelerator: -machine accel=xyz,
>>>>> -accel xyz and -enable-xyz. For new QEMU users, this must be very
>>>>> confusing ("Which one do I have to use? Is there a difference between
>>>>> the options?"). While -enable-kvm was useful in the past, there is no
>>>>> real good reason for using it anymore today ("-accel kvm" is even less
>>>>> to type than "-enable-kvm"), so let's decrease the confusing amount of
>>>>> options in our documenation a little bit by removing the -enable-xyz
>>>>> here. Note that the option itself is neither removed nor marked as
>>>>> deprecated - since -enable-kvm is likely used in a lot of scripts and
>>>>> since its code is easy to maintain, we should keep it around to avoid
>>>>> to break old setups.
>>>>>
>>>>> Signed-off-by: Thomas Huth <address@hidden>
>>>>> ---
>>>>>  PS: I guess Paolo won't like this patch ... let's try it anyway ;-)
>>>>
>>>> It's widely used and we're removing the documentation for it?!  That is
>>>> likely to cause issues for new users who refer to the man page to
>>>> understand the QEMU command-lines they see online, in scripts, etc.
>>>
>>> Agreed, this is a very bad idea. Any option that is accepted by QEMU,
>>> but not documented is a bug that must be fixed. IOW removing docs
>>> is creating bugs.
>>
>> Not documenting unliked options that are still kept for compatibility
>> was at least a common practice in the past (see -no-kvm for example, or
>> many of those deprecated options like -net channel that have been
>> removed in the past year).
> 
> If we're planning to deprecate & then delete an option, then I
> don't mind if docs are dropped, but IIUC, in this case we're
> not doing that - the option will essentially exist forever.
> 
>>> If we want to help users understand why we have -enable-kvm, just
>>> make the docs say that it is syntactic for '-machine accel=kvm'.
>>> Users can decide for themselves whether they want to switch to
>>> the more verbose way or not
>>
>> Uh, well, in this case "-enable-kvm" is already the more verbose way:
>> "-accel kvm" is shorter :-)
> 
> If I'm a user looking for how to enable KVM, then -enable-kvm is the
> one I'll pick because of the obvious name.

Hmm, maybe we should also add -configure-network-backend,
--configure-character-device-backend and -setup-block-backend as
synonyms for -netdev, -chardev and -blockdev, just because they have a
more obvious name? ;-)

 Thomas



reply via email to

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