qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/5] Removal of deprecated -no-kvm* options


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH v2 0/5] Removal of deprecated -no-kvm* options
Date: Mon, 7 May 2018 07:09:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 04.05.2018 23:57, Paolo Bonzini wrote:
> On 04/05/2018 19:01, Thomas Huth wrote:
>> The -no-kvm* options are a remainder of the ancient "qemu-kvm"
>> fork. They have never been officially documented in our qemu-doc,
>> they have been marked as deprecated in the sources since a very
>> long time, and we've marked them as deprecated in our qemu-doc
>> since QEMU v2.10. So far I haven't seen any complaints that we
>> should keep them, so it's time to remove these old parameters now.
>>
>> While I'm at it, this patch series also removes a left-over from
>> the "-tdf" option (which has been removed with QEMU v2.12) and
>> fixes a deficiency in the option parsing code that has been
>> revealed by the remainder of the "-tdf" option.
>>
>> Thomas Huth (5):
>>   qemu-options: Remove remainders of the -tdf option
>>   qemu-options: Bail out on unsupported options instead of silently
>>     ignoring them
>>   qemu-options: Remove deprecated -no-kvm-pit-reinjection
>>   qemu-options: Remove deprecated -no-kvm-irqchip
>>   qemu-options: Remove deprecated -no-kvm
> 
> I'm not that sure anymore about -no-kvm.  It can come in handy for
> distros (*cough* RHEL *cough) that only ship a qemu-kvm binary with
> default accelerator "-machine accel=kvm:tcg".

Actually, I expected someone to complain like this :-) That's also why I
kept the patches separate instead of doing one big remove-all-no-kvm
parameters patch. I also remember seeing some people still using this
option (in bug tickets etc.), so it's fine for me if we decide to keep
-no-kvm for now.

Question is, should we keep it just for some more few releases and then
remove it? In that case we should maybe add a patch that prints out a
warning message if somebody still tries to use it. Or do we rather want
to keep it around forever? In that case we should likely remove the
entry from the deprecation list.

 Thomas





reply via email to

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