From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH]: Always use KVM_VERSION to build version number Date: Sun, 09 Aug 2009 12:58:01 +0300 Message-ID: <4A7E9DA9.3060204@redhat.com> References: <4A7C1E96.3060200@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Chris Lalancette Return-path: Received: from mx2.redhat.com ([66.187.237.31]:59919 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753646AbZHIJwH (ORCPT ); Sun, 9 Aug 2009 05:52:07 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n799q8ZA015129 for ; Sun, 9 Aug 2009 05:52:08 -0400 In-Reply-To: <4A7C1E96.3060200@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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