From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57044 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Odmj6-0006wC-PG for qemu-devel@nongnu.org; Tue, 27 Jul 2010 12:09:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Odmj1-0002Pf-B9 for qemu-devel@nongnu.org; Tue, 27 Jul 2010 12:09:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55202) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Odmj1-0002PP-0h for qemu-devel@nongnu.org; Tue, 27 Jul 2010 12:09:51 -0400 Date: Tue, 27 Jul 2010 17:09:42 +0100 From: "Daniel P. Berrange" Message-ID: <20100727160942.GQ12387@redhat.com> References: <1280246103-6636-1-git-send-email-aliguori@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1280246103-6636-1-git-send-email-aliguori@us.ibm.com> Subject: [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , libvirt-list@redhat.com, qemu-devel@nongnu.org, Cole Robinson 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. Adding a one-off special case for the 0.13 release that we know will be obsolete in 0.14, 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 -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|