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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
