On Tue, Jul 27, 2010 at 10:26:10AM +0200, Markus Armbruster wrote:
> Anthony Liguori writes:
>
> > On 07/26/2010 02:19 PM, Avi Kivity wrote:
> [...]
> >> Regardless, outside of Windows users qemu will mostly be consumed
> >> via distribution branches, with different levels of backport
> >> happin
On 07/27/2010 08:50 AM, Anthony Liguori wrote:
> On 07/27/2010 07:30 AM, Cole Robinson wrote:
>> On 07/27/2010 05:47 AM, Jes Sorensen wrote:
>>
>>> On 07/27/10 10:11, Markus Armbruster wrote:
>>>
Anthony Liguori writes:
> On 07/26/2010 02:19 PM, Avi Kivity wrote:
>>
>>> On 7/27/2010 at 04:26 AM, "Daniel P. Berrange"
>>> wrote:
> On Wed, Jul 21, 2010 at 02:32:28PM -0600, Bruce Rogers wrote:
>> Libvirt parses qemu help output to determine qemu features. In particular
>> it probes for the following: "cache=writethrough|writeback|none". The
>> addition of t
On 07/27/2010 07:30 AM, Cole Robinson wrote:
On 07/27/2010 05:47 AM, Jes Sorensen wrote:
On 07/27/10 10:11, Markus Armbruster wrote:
Anthony Liguori writes:
On 07/26/2010 02:19 PM, Avi Kivity wrote:
We should try to support all users, prioritized by the number of
On 07/27/2010 05:47 AM, Jes Sorensen wrote:
> On 07/27/10 10:11, Markus Armbruster wrote:
>> Anthony Liguori 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 la
On Wed, Jul 21, 2010 at 02:32:28PM -0600, Bruce Rogers wrote:
> Libvirt parses qemu help output to determine qemu features. In particular
> it probes for the following: "cache=writethrough|writeback|none". The
> addition of the unsafe cache mode was inserted within this string, as
> opposed to b
On 07/27/10 10:11, Markus Armbruster wrote:
> Anthony Liguori 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 i
Am 26.07.2010 17:53, schrieb Anthony Liguori:
> 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.
As a practical guy you should s
Anthony Liguori writes:
> On 07/26/2010 02:19 PM, Avi Kivity wrote:
[...]
>> Regardless, outside of Windows users qemu will mostly be consumed
>> via distribution branches, with different levels of backport
>> happiness. We should recognize that and work with it, not against
>> it.
>
> And it's
Anthony Liguori writes:
> On 07/26/2010 02:19 PM, Avi Kivity wrote:
>>> Is what we are supporting just what libvirt expects there to be or
>>> what any tool out there expects there to be?
>>
>> We should try to support all users, prioritized by the number of end
>> users they represent. If this
On 07/26/2010 02:43 PM, Avi Kivity wrote:
On 07/26/2010 10:35 PM, Anthony Liguori wrote:
That's a bogus scenario because said evil distro would also enhance
libvirt to detect the feature properly.
That means a new libvirt release is needed.
Which if you're a distro and you backport a KVM fe
On 07/26/2010 10:35 PM, Anthony Liguori wrote:
If you want libvirt to do the right thing, provide a proper
capabilities interface. Using the version has its downsides as
much as the help text.
That's simply not the case. Please, provide an actual example where
version is not reliable a
On 07/26/2010 02:19 PM, Avi Kivity wrote:
Is what we are supporting just what libvirt expects there to be or
what any tool out there expects there to be?
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
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 w
On 07/26/2010 09:59 PM, Anthony Liguori wrote:
If libvirt is going to parse -help output, they should do a better
job at it. I can't expect QEMU developers to have detailed
knowledge of how libvirt parses the help output to ensure that we
don't break their code.
Correct. libvirt could have
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 break
On 07/26/2010 11:54 AM, Avi Kivity wrote:
Older versions of libvirt aren't a problem, they simply don't know
about cache=unsafe.
Let's be clear what's happening here. QEMU produces:
" [,cache=writethrough|writeback|unsafe|none][,format=f]\n"
Which is completely reasonable from a
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.
On 07/26/2010 07:40 PM, Anthony Liguori wrote:
On 07/26/2010 11:26 AM, Avi Kivity wrote:
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 rec
On 07/26/2010 11:26 AM, Avi Kivity wrote:
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.
It generates a dependency. If the do
On 07/26/2010 06:53 PM, Anthony Liguori wrote:
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.
On 07/23/2010 03:00 AM, Markus Armbruster wrote:
Anthony Liguori 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.
Anthony Liguori 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
On 07/22/2010 03:42 AM, Daniel P. Berrange wrote:
On Wed, Jul 21, 2010 at 06:39:32PM -0500, Anthony Liguori wrote:
On 07/21/2010 04:58 PM, Daniel P. Berrange wrote:
Yes there is. Use the version number.
The version number is not suitable, because features can be removed a
On Wed, 21 Jul 2010 15:55:28 -0500
Anthony Liguori wrote:
> On 07/21/2010 03:32 PM, Bruce Rogers wrote:
> > Libvirt parses qemu help output to determine qemu features. In particular
> > it probes for the following: "cache=writethrough|writeback|none". The
> > addition of the unsafe cache mode
On Wed, Jul 21, 2010 at 06:39:32PM -0500, Anthony Liguori wrote:
> On 07/21/2010 04:58 PM, Daniel P. Berrange wrote:
> >>Yes there is. Use the version number.
> >>
> >The version number is not suitable, because features can be removed at
> >compile time and/or
>
> I don't see any features th
Anthony Liguori writes:
> On 07/21/2010 04:58 PM, Daniel P. Berrange wrote:
>>> Yes there is. Use the version number.
>>>
>> The version number is not suitable, because features can be removed at
>> compile time and/or
>
> I don't see any features that libvirt would need to know about that
Anthony Liguori wrote:
> On 07/21/2010 04:58 PM, Daniel P. Berrange wrote:
> >>Yes there is. Use the version number.
> >>
> >The version number is not suitable, because features can be removed at
> >compile time and/or
>
> I don't see any features that libvirt would need to know about that a
On 07/21/2010 04:58 PM, Daniel P. Berrange wrote:
Yes there is. Use the version number.
The version number is not suitable, because features can be removed at
compile time and/or
I don't see any features that libvirt would need to know about that are
disabled at compile time that aren'
On Wed, Jul 21, 2010 at 04:45:46PM -0500, Anthony Liguori wrote:
> On 07/21/2010 04:32 PM, Daniel P. Berrange wrote:
> >On Wed, Jul 21, 2010 at 03:55:28PM -0500, Anthony Liguori wrote:
> >
> >>On 07/21/2010 03:32 PM, Bruce Rogers wrote:
> >>
> >>>Libvirt parses qemu help output to determine
On 07/21/2010 04:32 PM, Daniel P. Berrange wrote:
On Wed, Jul 21, 2010 at 03:55:28PM -0500, Anthony Liguori wrote:
On 07/21/2010 03:32 PM, Bruce Rogers wrote:
Libvirt parses qemu help output to determine qemu features. In particular
it probes for the following: "cache=writethrough|w
On Wed, Jul 21, 2010 at 03:55:28PM -0500, Anthony Liguori wrote:
> On 07/21/2010 03:32 PM, Bruce Rogers wrote:
> >Libvirt parses qemu help output to determine qemu features. In particular
> > it probes for the following: "cache=writethrough|writeback|none". The
> > addition of the unsafe cache mo
On 07/21/2010 03:32 PM, Bruce Rogers wrote:
Libvirt parses qemu help output to determine qemu features. In particular
it probes for the following: "cache=writethrough|writeback|none". The
addition of the unsafe cache mode was inserted within this string, as
opposed to being added to the end
Libvirt parses qemu help output to determine qemu features. In particular
it probes for the following: "cache=writethrough|writeback|none". The
addition of the unsafe cache mode was inserted within this string, as
opposed to being added to the end, which impacted libvirt's probe.
Unbreak libvir
34 matches
Mail list logo
