[PATCH]: Always use KVM_VERSION to build version number

[PATCH]: Always use KVM_VERSION to build version number

[Chris Lalancette]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

Avi,
     Trying to use libvirt with development snapshots of qemu-kvm is a bit
problematic.  The trouble is that for all development snapshots, the value that
gets placed into this string:

QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008

Is always kvm-devel.  That means we can't tell if this is a kvm development
snapshot built yesterday, or 6 months ago, which means that in turn we can't
tell what features are available.  While we can always tell people building
their own qemu to force it by echoing a value into KVM_VERSION, it would be much
better if this were done by default.  Something like kvm-88-devel, which would
signify that this the development happening after kvm-88, leading towards
kvm-89.  Would you accept something like the patch below, which would require
you to edit the KVM_VERSION file twice during a release (once right before the
release, to change it to kvm-89, and once right after the release to change it
back to kvm-89-devel)?

Signed-off-by: Chris Lalancette <clalance@redhat.com>

[-- Attachment #2: kvm-version.patch --]
[-- Type: text/x-patch, Size: 143 bytes --]

diff --git a/KVM_VERSION b/KVM_VERSION
new file mode 100644
index 0000000..efd3e0e
--- /dev/null
+++ b/KVM_VERSION
@@ -0,0 +1 @@
+kvm-88-devel

Re: [PATCH]: Always use KVM_VERSION to build version number

[Avi Kivity]

On 08/07/2009 03:31 PM, Chris Lalancette wrote:
> Avi,
>       Trying to use libvirt with development snapshots of qemu-kvm is a bit
> problematic.  The trouble is that for all development snapshots, the value that
> gets placed into this string:
>
> QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008
>
> Is always kvm-devel.  That means we can't tell if this is a kvm development
> snapshot built yesterday, or 6 months ago, which means that in turn we can't
> tell what features are available.  While we can always tell people building
> their own qemu to force it by echoing a value into KVM_VERSION, it would be much
> better if this were done by default.  Something like kvm-88-devel, which would
> signify that this the development happening after kvm-88, leading towards
> kvm-89.  Would you accept something like the patch below, which would require
> you to edit the KVM_VERSION file twice during a release (once right before the
> release, to change it to kvm-89, and once right after the release to change it
> back to kvm-89-devel)?
>
>    

This is problematic in two ways.  One is that I am basically guaranteed 
to forget to edit the file (which is why the release scripts generate 
the name based on the tag).

On fix is to use git describe --match to find out what's the closest 
release.  But this is still quite bad as it doesn't account for branches 
and forks.

How about adding 'qemu -describe-features' which will output, one line 
per feature, what's supported (and limits where applicable)?  I 
understand libvirt already does this for some features using -help; this 
is simply a formalization of that hack.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH]: Always use KVM_VERSION to build version number

[Mark McLoughlin]

On Sun, 2009-08-09 at 12:58 +0300, Avi Kivity wrote:
> On 08/07/2009 03:31 PM, Chris Lalancette wrote:
> > Avi,
> >       Trying to use libvirt with development snapshots of qemu-kvm is a bit
> > problematic.  The trouble is that for all development snapshots, the value that
> > gets placed into this string:
> >
> > QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008
> >
> > Is always kvm-devel.  That means we can't tell if this is a kvm development
> > snapshot built yesterday, or 6 months ago, which means that in turn we can't
> > tell what features are available.  While we can always tell people building
> > their own qemu to force it by echoing a value into KVM_VERSION, it would be much
> > better if this were done by default.  Something like kvm-88-devel, which would
> > signify that this the development happening after kvm-88, leading towards
> > kvm-89.  Would you accept something like the patch below, which would require
> > you to edit the KVM_VERSION file twice during a release (once right before the
> > release, to change it to kvm-89, and once right after the release to change it
> > back to kvm-89-devel)?
> >
> >    
> 
> This is problematic in two ways.  One is that I am basically guaranteed 
> to forget to edit the file (which is why the release scripts generate 
> the name based on the tag).

Anthony manages to remember to update VERSION :-)

> On fix is to use git describe --match to find out what's the closest 
> release.  But this is still quite bad as it doesn't account for branches 
> and forks.

Or we could drop this kvm snapshot numbering system and just use qemu
VERSION numbering - i.e. qemu-kvm-devel-88 could have been published as
qemu-kvm-0.10.50

> How about adding 'qemu -describe-features' which will output, one line 
> per feature, what's supported (and limits where applicable)?  I 
> understand libvirt already does this for some features using -help; this 
> is simply a formalization of that hack.

Yes, libvirt would much rather not parse -help or use version numbers to
detect whether features are available.

We should revisit the "info capabilities" thing again:

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

Cheers,
Mark.

[PATCH] configure: make default KVM_VERSION qemu-kvm-devel

[Mark McLoughlin]

Released versions of qemu-kvm now have a KVM_VERSION of either
qemu-kvm-x.y.z or qemu-kvm-devel-XX. However, when building from git,
KVM_VERSION is kvm-devel.

Defaulting to qemu-kvm-devel makes more sense.

With newer versions of qemu-kvm, libvirt actually ignores the kvm
snapshot number (i.e. 86, 87 etc.) and just uses the 'qemu-kvm-'
string to detect that this is the kvm fork of qemu. The actual kvm
snapshot number is no longer important, it's the qemu version number
which is important.

Signed-off-by: Mark McLoughlin <markmc@redhat.com>
---
 configure |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index 62028ca..cf8c4e6 100755
--- a/configure
+++ b/configure
@@ -166,7 +166,7 @@ kvm_version() {
     if test -f "$fname"; then
         cat "$fname"
     else
-        echo "kvm-devel"
+        echo "qemu-kvm-devel"
     fi
 }
 
-- 
1.6.2.5

Re: [PATCH] configure: make default KVM_VERSION qemu-kvm-devel

[Avi Kivity]

On 08/10/2009 12:39 PM, Mark McLoughlin wrote:
> Released versions of qemu-kvm now have a KVM_VERSION of either
> qemu-kvm-x.y.z or qemu-kvm-devel-XX. However, when building from git,
> KVM_VERSION is kvm-devel.
>
> Defaulting to qemu-kvm-devel makes more sense.
>
> With newer versions of qemu-kvm, libvirt actually ignores the kvm
> snapshot number (i.e. 86, 87 etc.) and just uses the 'qemu-kvm-'
> string to detect that this is the kvm fork of qemu. The actual kvm
> snapshot number is no longer important, it's the qemu version number
> which is important.
>    

Applied, thanks.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH]: Always use KVM_VERSION to build version number

[Avi Kivity]

On 08/10/2009 12:19 PM, Mark McLoughlin wrote:
>> This is problematic in two ways.  One is that I am basically guaranteed
>> to forget to edit the file (which is why the release scripts generate
>> the name based on the tag).
>>      
>
> Anthony manages to remember to update VERSION :-)
>    

I'm not Anthony.

>> On fix is to use git describe --match to find out what's the closest
>> release.  But this is still quite bad as it doesn't account for branches
>> and forks.
>>      
>
> Or we could drop this kvm snapshot numbering system and just use qemu
> VERSION numbering - i.e. qemu-kvm-devel-88 could have been published as
> qemu-kvm-0.10.50
>    

Yeah.  You still couldn't distinguish among different snapshots.

>> How about adding 'qemu -describe-features' which will output, one line
>> per feature, what's supported (and limits where applicable)?  I
>> understand libvirt already does this for some features using -help; this
>> is simply a formalization of that hack.
>>      
>
> Yes, libvirt would much rather not parse -help or use version numbers to
> detect whether features are available.
>
> We should revisit the "info capabilities" thing again:
>
>    http://lists.gnu.org/archive/html/qemu-devel/2008-11/msg00767.html
>    

Logically it needs to work before starting a VM, so a command line 
option is more appropriate.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH]: Always use KVM_VERSION to build version number

[Mark McLoughlin]

On Mon, 2009-08-10 at 12:46 +0300, Avi Kivity wrote:
> On 08/10/2009 12:19 PM, Mark McLoughlin wrote:
> >
> > Or we could drop this kvm snapshot numbering system and just use qemu
> > VERSION numbering - i.e. qemu-kvm-devel-88 could have been published as
> > qemu-kvm-0.10.50
> >    
> 
> Yeah.  You still couldn't distinguish among different snapshots.

0.10.51, 0.10.52 etc.

> >> How about adding 'qemu -describe-features' which will output, one line
> >> per feature, what's supported (and limits where applicable)?  I
> >> understand libvirt already does this for some features using -help; this
> >> is simply a formalization of that hack.
> >>      
> >
> > Yes, libvirt would much rather not parse -help or use version numbers to
> > detect whether features are available.
> >
> > We should revisit the "info capabilities" thing again:
> >
> >    http://lists.gnu.org/archive/html/qemu-devel/2008-11/msg00767.html
> >    
> 
> Logically it needs to work before starting a VM, so a command line 
> option is more appropriate.

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

Cheers,
Mark.

Re: [PATCH]: Always use KVM_VERSION to build version number

[Avi Kivity]

On 08/10/2009 12:52 PM, Mark McLoughlin wrote:
> On Mon, 2009-08-10 at 12:46 +0300, Avi Kivity wrote:
>    
>> On 08/10/2009 12:19 PM, Mark McLoughlin wrote:
>>      
>>> Or we could drop this kvm snapshot numbering system and just use qemu
>>> VERSION numbering - i.e. qemu-kvm-devel-88 could have been published as
>>> qemu-kvm-0.10.50
>>>
>>>        
>> Yeah.  You still couldn't distinguish among different snapshots.
>>      
>
> 0.10.51, 0.10.52 etc.
>    

The "50" is owned by upstream, so 0.10.50.1.

>> Logically it needs to work before starting a VM, so a command line
>> option is more appropriate.
>>      
>
> http://lists.gnu.org/archive/html/qemu-devel/2008-11/msg00899.html
>    

http://implement.it.already

-- 
error compiling committee.c: too many arguments to function