From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54732 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCwV9-0001BY-42 for qemu-devel@nongnu.org; Fri, 14 May 2010 11:08:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCwV7-00009y-2M for qemu-devel@nongnu.org; Fri, 14 May 2010 11:08:34 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:35679) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCwV6-00009e-Gc for qemu-devel@nongnu.org; Fri, 14 May 2010 11:08:32 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o4EAw1FY002296 for ; Fri, 14 May 2010 06:58:01 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4EF8S5v1462448 for ; Fri, 14 May 2010 11:08:28 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4EF8R6t014958 for ; Fri, 14 May 2010 11:08:27 -0400 Message-ID: <4BED6769.1010608@linux.vnet.ibm.com> Date: Fri, 14 May 2010 10:08:25 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Revive -version 'QEMU PC Emulator...' References: <4BEB11DD.20601@redhat.com> <4BEB142F.2000002@redhat.com> <4BEBB9C2.3050302@redhat.com> <4BEBF8D1.7060401@redhat.com> <4BEBF9A5.3070507@redhat.com> <4BED4EF9.3090800@linux.vnet.ibm.com> <20100514135426.GJ9282@redhat.com> <4BED5CBF.8060505@linux.vnet.ibm.com> <20100514144251.GM9282@redhat.com> <4BED63C5.2040501@codemonkey.ws> <20100514150255.GN9282@redhat.com> In-Reply-To: <20100514150255.GN9282@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Jes Sorensen , clalance@redhat.com, qemu-devel@nongnu.org, Cole Robinson On 05/14/2010 10:02 AM, Daniel P. Berrange wrote: > On Fri, May 14, 2010 at 09:52:53AM -0500, Anthony Liguori wrote: > >> On 05/14/2010 09:42 AM, Daniel P. Berrange wrote: >> >>> It is preferable to query the explicit capability wanted, because >>> version numbers are useless when distros backport features, >>> >> Unless distros add their own release number to the version information >> and libvirt learns about the features they add. >> > And features removed / compiled out. eg SDL removed, es1370 sound driver > removed, etc, etc. > > Version numbers are a really bad way to determine availability of > functionality. You end up having to build a giant matrix of features > vs version numbers, which will be outdated the moment its created. > You need version numbers to understand behavior. If you also want to know compile settings, we need the equivalent of /proc/config (a simple -build-config command could output our build config). > If you want feature X, you need to be able to check for prescense of > feature X, not infer it from another piece of information that is > only loosely related. > You assume that feature X is idempotent across multiple downstreams. That's not a realistic assumption IMHO. > eg, if you want to use a kernel filesystem, you don't perform a check > a kernel version number, because its inevitably wrong. You check > /proc/filesystems to see if the filesystem is supported. > And we have this today with QMP. It provides a mechanism to query capabilities. Fundamentally, this is a bootstrap problem and the best way to bootstrap is with a version number. >> I think that's the sanest approach. Just because a distro backports a >> feature doesn't mean that it behaves like the upstream version. libvirt >> really needs to treat distro packages as separate entities from upstream >> IMHO. >> > If a distro changes the semantics of a upstream feature everyone looses > no matter which way you look at it. > It's a reality so we have to deal with it. Regards, Anthony Liguori > Daniel >