[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help
Date: Mon, 26 Jul 2010 10:53:56 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100528 Lightning/1.0b1 Thunderbird/3.0.5

On 07/23/2010 03:00 AM, Markus Armbruster wrote:
Anthony Liguori<address@hidden>  writes:

On 07/22/2010 03:42 AM, Daniel P. Berrange wrote:
On Wed, Jul 21, 2010 at 06:39:32PM -0500, Anthony Liguori wrote:
If a distro backports a feature, it should change the QEMU version
string.  If it doesn't, that's a distro problem.

This puts you in the position of having to maintain an ever changing
giant compatability table between version numbers and features, which
just results in madness.

Or working with QEMU to have a better solution.

We've been complaining for a long time about parsing help output and
we've made changes as "temporary" stop gaps for libvirt too many times
in the past.

This problem needs to get fixed properly.
You almost sound like Dan refused to consider anything but parsing help
output, like it were Dan's fault that QEMU still doesn't provide a
usable interface for querying its capabilities, and like the way to get
it was to put more pressure on Dan.

I'm not blaming anyone. As I see it, we have a supported interface for determining which interfaces are supported by a given version of QEMU--the version number. If the version number is not reliable because downstreams backport features in an undetectable way, that is not our (upstream) problem.

I'm a practical guy, and I don't see that it's a huge burden for libvirt to detect downstreams and build a feature matrix based on versions. If someone demonstrates that it's infeasible, I'll happily reconsider.

That would be unfair.  Dan posted patches to fix this problem properly,
which puts the ball squarely in our court.

The patches are a good step, but they don't solve the problem. There will always be older versions of libvirt and older versions of QEMU so what's libvirt going to do with those?

   Could we please refrain from
gratuitously fscking up libvirt just a bit longer, until we finish
improving and merging Dan's patches?

Even without doing version based feature detection, libvirt could just do a better job of parsing the help output.

The help output is *not* a supported interface. There are very simple changes libvirt can and should make. The fix to this "problem" belongs in libvirt, no QEMU.


Anthony Liguori


reply via email to

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