Skip to contentSkip to conversation

: Always use KVM_VERSION to build version number

PATCH In review Chris Lalancette 3 participants 8 messages Aug 7, 2009 – Aug 10, 2009 KVM

lore
Share & tools
lore

Chris Lalancette

author
#0 lore raw

PATCH 1/1 : Always use KVM_VERSION to build version number

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 <[email protected]>
KVM_VERSION new file +1 -0
new file mode 100644
index 0000000..efd3e0e
@@ -0,0 +1 @@
+kvm-88-devel
#1 lore raw
Quoted 7 lines · Chris Lalancette

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

Quoted 12 lines

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.

Signature · 1 line
error compiling committee.c: too many arguments to function
#2 lore raw
Quoted 21 lines · Avi Kivity
Quoted 7 lines · Chris Lalancette

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

Quoted 12 lines

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)?

Quoted 3 lines

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 :-)

Quoted 3 lines

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

Quoted 4 lines

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.

#3 lore raw

PATCH 1/1 configure: make default KVM_VERSION qemu-kvm-devel

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 <[email protected]>
---
 configure |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
configure +1 -1
index 62028ca..cf8c4e6 100755
@@ -166,7 +166,7 @@ kvm_version() {
     if test -f "$fname"; then
         cat "$fname"
     else
-        echo "kvm-devel"
+        echo "qemu-kvm-devel"
     fi
 }
Signature · 1 line
1.6.2.5
Applied
#4 lore raw

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

Quoted 4 lines · 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.

Quoted 8 lines

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.

Signature · 1 line
error compiling committee.c: too many arguments to function
#5 lore raw
In reply to Mark McLoughlin
Quoted 7 lines · Mark McLoughlin
Quoted 4 lines

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.

Quoted 9 lines
Quoted 4 lines

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.

Quoted 6 lines
Quoted 5 lines

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.

Quoted 7 lines

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.

Signature · 1 line
error compiling committee.c: too many arguments to function
#6 lore raw
Quoted 8 lines · Avi Kivity
Quoted 5 lines · Mark McLoughlin

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.

Quoted 9 lines
Quoted 9 lines
Quoted 5 lines

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.

Quoted 7 lines
Quoted 4 lines

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.

#7 lore raw
Quoted 9 lines · Mark McLoughlin
Quoted 7 lines · Avi Kivity
Quoted 5 lines · Mark McLoughlin

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

Quoted 5 lines
Quoted 2 lines

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.

Quoted 6 lines
Quoted 3 lines

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

Signature · 1 line
error compiling committee.c: too many arguments to function