| Message ID | 4A7C1E96.3060200@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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>