From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45299 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oe6vi-0005B4-NQ for qemu-devel@nongnu.org; Wed, 28 Jul 2010 09:44:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oe6vh-0007Ta-CM for qemu-devel@nongnu.org; Wed, 28 Jul 2010 09:44:18 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:40914) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oe6vh-0007TO-8T for qemu-devel@nongnu.org; Wed, 28 Jul 2010 09:44:17 -0400 Received: by yxn35 with SMTP id 35so1010527yxn.4 for ; Wed, 28 Jul 2010 06:44:16 -0700 (PDT) Message-ID: <4C503431.1080703@codemonkey.ws> Date: Wed, 28 Jul 2010 08:44:17 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap References: <1280246103-6636-1-git-send-email-aliguori@us.ibm.com> <20100727160942.GQ12387@redhat.com> <4C4F0B6C.2030804@codemonkey.ws> <20100727170030.GT12387@redhat.com> <4C4F1577.20500@codemonkey.ws> <20100728095318.GB13934@redhat.com> In-Reply-To: <20100728095318.GB13934@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: Chris Wright , qemu-devel@nongnu.org, libvirt-list@redhat.com, Cole Robinson On 07/28/2010 04:53 AM, Daniel P. Berrange wrote: > On Tue, Jul 27, 2010 at 12:20:55PM -0500, Anthony Liguori wrote: > >> On 07/27/2010 12:00 PM, Daniel P. Berrange wrote: >> >>>> Yup. You'll need to decide up front if you want to probe for a feature >>>> when it's introduced and have something added to capabilities. >>>> >>>> This is simple though. A few weeks before 0.14 is released, go through >>>> the change log, and anything that looks interesting, add a cap flag. >>>> >>>> >>> That doesn't work for features which already exist in QEMU which are >>> not yet supported in libvirt. eg consider QEMU 0.13 is released, and >>> then we want to add a new feature to libvirt a month later. >>> >> Right. So sit down and look at the 0.13 changelog and if there's any >> features that you think you might want to support at some point in time, >> add a capability. >> > Not really practical - pretty much anything is a candidate because > we want to support as many of QEMU features as possible. > > >>> It offers significantly less information that the existing -help >>> data, so I don't think it is workable as a replacement. We'd get >>> into the bad situation where we could support a feature in 0.12 >>> but not in 0.13, unless we went back to using -help output again. >>> >>> If we're going for a short term hack, then how about a combination >>> of >>> >>> http://www.mail-archive.com/qemu-devel@nongnu.org/msg34944.html >>> http://www.mail-archive.com/qemu-devel@nongnu.org/msg34960.html >>> >>> >> Would have failed in exactly the same way that the current -help parsing >> fails. The description of an argument in the help text is not a >> capabilities string. >> > This particular case of cache modes might have failed, but in the > broader picture it would have been more reliable. The vasty > majority of the time, we only check whether a particular named > argument exists. This patch would make it very reliable todo so > because you could simply extract a single named field from the > JSON doc. The cases where we looked at the parameter options > would have been improved a little, but still be potentially fragile. > Checking for version number would also be improved. So overall > while obviously not perfect, it would be significantly better than > the solution today and using an approach that isn't a complete > throwaway solution. > I'd be willing to spit out the option names minus the help descriptions. The option names are part of a supported interface so there's no harm in exposing an interface for that. But I think libvirt really needs option names + indication when we've added parameters to an option, right? Regards, Anthony Liguori > Regards, > Daniel >