From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52198 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdnAQ-0001Ax-10 for qemu-devel@nongnu.org; Tue, 27 Jul 2010 12:38:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OdnAO-0006C5-6W for qemu-devel@nongnu.org; Tue, 27 Jul 2010 12:38:09 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:48905) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdnAO-0006By-34 for qemu-devel@nongnu.org; Tue, 27 Jul 2010 12:38:08 -0400 Received: by qwi4 with SMTP id 4so864103qwi.4 for ; Tue, 27 Jul 2010 09:38:07 -0700 (PDT) Message-ID: <4C4F0B6C.2030804@codemonkey.ws> Date: Tue, 27 Jul 2010 11:38:04 -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> In-Reply-To: <20100727160942.GQ12387@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 , Cole Robinson , libvirt-list@redhat.com, qemu-devel@nongnu.org On 07/27/2010 11:09 AM, Daniel P. Berrange wrote: > On Tue, Jul 27, 2010 at 10:55:03AM -0500, Anthony Liguori wrote: > >> Today libvirt parses -help output to attempt to enumerate capabilities. This >> is very broken and has led to multiple failures. Since libvirt is an important >> management interface to QEMU, we need to do a better job giving them the ability >> to detect what a QEMU executable supports. Right now, we keep fixing up help >> output to appease it's parsing code but this is undesirable. >> >> The Right Solution is to introduce a robust capabilities advertisement that >> enumerates every feature we have. As with most Right Solutions, we don't have >> mergable code today and it's unclear that we'll get there by the next release. >> >> This patch introduces an incremental solution of just spitting out the handful >> of capabilities libvirt is probing for today. This interface will need to >> remain forever but can stop being updated once we have a Right Solution. >> > This isn't really workable because it only encodes the subset of things > that libvirt currently looks for. If someone comes along with a libvirt > patch for a new features that is already supported by QEMU, but isn't > in this simple output, we're stuck. 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. > Adding a one-off special case for > the 0.13 release that we know will be obsolete in 0.14 IIF capabilities gets merged by 0.14. I'd certainly like it to, but I'd prefer to hedge my bets. Here are the possible things we can do: 1) merge -libvirt-caps as an intermediate solution, stop caring about -help changes, when full caps are introduced, stop updating -libvirt-caps 2) don't merge -libvirt-caps, stop caring about -help changes, put everything on getting full caps merged by 0.14 3) don't merge -libvirt-caps, care about making -help changes, use -help as the caps mechanism until full caps get merged We can't do (3). I'm going to revert the -help changes for 0.13 so that old versions of libvirt work but not for master. (2) makes me pretty uncomfortable because it implies either (a) delay 0.14 until full caps are ready (b) ship 0.14 such that libvirt is totally broken. (1) isn't ideal, I'll freely admit, but it's a workable intermediate solution. Regards, Anthony Liguori > , and obviously > can't be used in qemu< 0.12 is not really a worthwhile use of time. > libvirt has to keep supporting help parsing indefinitely for<= 0.12 > releases& expects to support a new extensible& flexible approach for > qemu>= 0.14. Adding a special case that both libvirt& qemu have to > support indefinitely for 0.13 is not really very nice. > > Daniel >