qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [libvirt] [PATCH 3/3] cirrus: mark as deprecated


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [libvirt] [PATCH 3/3] cirrus: mark as deprecated
Date: Fri, 26 Oct 2018 15:25:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1


On 10/26/2018 11:42 AM, Daniel P. Berrangé wrote:
> On Fri, Oct 26, 2018 at 12:33:55PM +0530, P J P wrote:
>>   Hello Dan, all
>>
>> +-- On Thu, 25 Oct 2018, Daniel P. Berrangé wrote --+
>> | On Thu, Oct 25, 2018 at 10:52:56AM +0200, Gerd Hoffmann wrote:
>> | > While being at it deprecate cirrus too.
>> | > 
>> | > Reason (short version): use stdvga instead.
>> | > Verbose version:
>> | >     
>> https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful
>> | 
>> | 
>> | I don't debate the points in the blog post above that stdvga is a
>> | better choice, but I don't think that's enough to justify deprecating
>> | cirrus at this point in time, because when it then gets deleted it
>> | will break way too many existing deployments.
>> | 
>> | We need to socialize info in that blog post above more widely and
>> | especially ensure that apps are not using that by default. I don't
>> | see it being viable to formally deprecate it in QEMU any time soon
>> | though given existing usage.
>>
>> To note, IMO there are other devices/sources in QEMU which are potential 
>> candidates for deprecation, similar to adlib etc. It'll help if we could 
>> device a process to deprecate/remove such code base. Other than maintenance 
>> it 
>> invariably also becomes source of security issues.
>>
>> Ex.(similar to Fedora) we could announce such candidate on qemu-devel list 
>> and 
>> after review over a period of say a month, candidate will be
>> deprecated/expunged. (thinking aloud)
> 
> QEMU has a deprecation process:
> 
>   https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
> 
> Most of the stuff deprecated is CLI args / monitor commands, etc where
> mgmt apps just adjust the way they are calling QEMU, so end user's VMs
> are largely not impacted.
> 
> Deprecating a device type that is widely used is not desirable because
> that will cause breakage of existing guests.  Distros are free to disable
> devices in their builds if they want to reduce the scope for CVEs in
> packages they maintain, but again they should think carefully about how
> many users they are going to break by doing so.

I agree with what Daniel said. Deprecating something that is in heavy use 
by users just because we have trouble maintaining it not going to help the
QEMU project - quite the opposite. 




reply via email to

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