qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH] move 'unsafe' to end of caching modes in help


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH] move 'unsafe' to end of caching modes in help
Date: Mon, 26 Jul 2010 21:43:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Avi Kivity <address@hidden> wrote:
>  On 07/26/2010 10:03 PM, Anthony Liguori wrote:
>> On 07/26/2010 11:29 AM, Avi Kivity wrote:
>>>  On 07/26/2010 07:26 PM, Avi Kivity wrote:
>>>>
>>>>> The help output is *not* a supported interface. 
>>>>
>>>> There is no supported, usable interface for this.
>>>
>>> Well actually, libvirt could probe this by starting qemu with
>>> cache=x for various x and seeing if it breaks.  But the milk has
>>> already been spilled.
>>
>> So we're stuck with supporting the help output as an interface
>> forever?   Even with a capabilities system, what about old versions
>> of libvirt?
>
> No, the rate of crap generation seems to increase all the time, we
> have to get rid of it eventually.  If we provide a replacement, give a
> warning, wait some months for libvirt^Wusers to catch up, and throw
> away the deprecated feature, we can remove any feature we like.  This
> is still a fast moving field and users to upgrade.  Just not every
> week.
>
>>
>> At some point in time, old versions of libvirt are going to stop
>> working with new versions of QEMU because the help output changes.
>> If libvirt switches to something more reliable (like versioning),
>> then the gap is closed until there is a capabilities system.
>>
>> There will be a breakage though and we shouldn't pretend that taking
>> this patch does anything other than delay that breakage.
>
> There's a difference between
> - planned breakage with a warning ahead of time
> - unplanned breakage
> - unplanned breakage with unwillingness to fix

Fully agree here.  We have lots of (mis)features that we want to
remove.  But one thing is just remove them, and another to remove
something before we create a valid alternative.

I am all for:

docs/deprecated-features.txt

And having there things that will be removed and when.

Later, Juan.



reply via email to

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