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

[Cole Robinson <crobinso@redhat.com>]

On 07/27/2010 05:47 AM, Jes Sorensen wrote:
> On 07/27/10 10:11, Markus Armbruster wrote:
>> Anthony Liguori <anthony@codemonkey.ws> writes:
>>> On 07/26/2010 02:19 PM, Avi Kivity wrote:
>>>> We should try to support all users, prioritized by the number of end
>>>> users they represent.  If this patch broke some other large user
>>>> we'd be in a bind.  But likely this isn't the case so we aren't.
>>>
>>> As I've said, I'm pragmatic and that's why I've argued for these
>>> changes in the past.  But libvirt should have changed a long time ago
>>> to using something more reliable (like version).
>>
>> You want pragmatic?  I can give you pragmatic!  We apply the trivial
>> patch that helps libvirt and hurts nobody, and save our breath & typing
>> for designing and implementing a capability system.
> 
> To be honest, this is exactly the same problem we had when the output
> from -version changed and libvirt broke because it did static string
> parsing instead of doing it properly. Back then the output of -version
> was changed back to accommodate libvirt, but I am not aware that libvirt
> went ahead and fixed the real problem in the mean time.
> 

The output of -version was not changed back, the revert was rejected.
(Meaning QEMU has no stable interface for determining version info.
Which is confusing, considering that the version string is now being
recommended as the interim capability reporting system.)

I also want to point out that the version string change is far worse
than the cache= issue: in this case, we won't set a user specified cache
value. In the version string case, nearly every existing libvirt
deployment is not going to be able to use qemu-0.13. Whoops! :(

No argument that these are libvirt parsing bugs, but it would be a good
faith gesture to revert these utterly trivial qemu changes until there's
a proper way forward (or some reasonable amount of time has passed).

> While I don't see this specific change being problematic, I don't like
> the trend of hacking things to accommodate a specific library or
> application, when the group relying on the feature really should start
> providing the code for the real solution.
> 

There is no trend. From a quick look of the logs, I couldn't find a
single commit attributed to appeasing libvirt that wasn't a qemu bug (or
related to QMP which is ongoing dev).

Also, the affected group (well, danpb really) _is_ supplying code for
the real solution, he made a post last month:

http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00921.html

There also was a previous attempt at a -capabilites option by markmc a
couple years back, but it fell by the wayside:

http://lists.gnu.org/archive/html/qemu-devel/2008-11/msg00767.html

- Cole