From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35631 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdkKF-0000um-5e for qemu-devel@nongnu.org; Tue, 27 Jul 2010 09:36:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OdkKA-0004YE-Qv for qemu-devel@nongnu.org; Tue, 27 Jul 2010 09:36:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41907) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdkKA-0004Y4-IZ for qemu-devel@nongnu.org; Tue, 27 Jul 2010 09:36:02 -0400 Message-ID: <4C4EE0BB.8080206@redhat.com> Date: Tue, 27 Jul 2010 09:35:55 -0400 From: Cole Robinson MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] move 'unsafe' to end of caching modes in help References: <4C4704FC020000480009AB6E@sinclair.provo.novell.com> <4C475EC0.2000805@codemonkey.ws> <20100721213238.GB28871@redhat.com> <4C476A8A.6000707@codemonkey.ws> <20100721215833.GC28871@redhat.com> <4C478534.2020106@codemonkey.ws> <20100722084225.GA1524@redhat.com> <4C485383.8020904@codemonkey.ws> <4C4DAF94.1040300@codemonkey.ws> <4C4DB74F.7090507@redhat.com> <4C4DBA71.1000808@codemonkey.ws> <4C4DBDCC.8090408@redhat.com> <4C4DDB25.90000@codemonkey.ws> <4C4DDFDC.3000608@redhat.com> <4C4DE38E.4050900@codemonkey.ws> <4C4EAB3E.6090306@redhat.com> <4C4ED164.8010107@redhat.com> <4C4ED617.1030100@codemonkey.ws> In-Reply-To: <4C4ED617.1030100@codemonkey.ws> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Jes Sorensen , Bruce Rogers , qemu-devel@nongnu.org, Markus Armbruster , Avi Kivity On 07/27/2010 08:50 AM, Anthony Liguori wrote: > On 07/27/2010 07:30 AM, Cole Robinson wrote: >> On 07/27/2010 05:47 AM, Jes Sorensen wrote: >> >>> On 07/27/10 10:11, Markus Armbruster wrote: >>> >>>> Anthony Liguori writes: >>>> >>>>> On 07/26/2010 02:19 PM, Avi Kivity wrote: >>>>> >>>>>> We should try to support all users, prioritized by the number of end >>>>>> users they represent. If this patch broke some other large user >>>>>> we'd be in a bind. But likely this isn't the case so we aren't. >>>>>> >>>>> As I've said, I'm pragmatic and that's why I've argued for these >>>>> changes in the past. But libvirt should have changed a long time ago >>>>> to using something more reliable (like version). >>>>> >>>> You want pragmatic? I can give you pragmatic! We apply the trivial >>>> patch that helps libvirt and hurts nobody, and save our breath& typing >>>> for designing and implementing a capability system. >>>> >>> To be honest, this is exactly the same problem we had when the output >>> from -version changed and libvirt broke because it did static string >>> parsing instead of doing it properly. Back then the output of -version >>> was changed back to accommodate libvirt, but I am not aware that libvirt >>> went ahead and fixed the real problem in the mean time. >>> >>> >> The output of -version was not changed back, the revert was rejected. >> (Meaning QEMU has no stable interface for determining version info. >> > > Actually, we do. 'info version' in the monitor returns just the version. > My bad, I didn't know about that. Then again, having to start up a qemu instance and connect to the monitor just to get a bare version string seems overkill. > Additionally, -version on the command line spits out just a single > version string. > I wouldn't really call that 'stable', figuring that the output was changed recently. > The trouble libvirt has is that it's parsing the help output and needs > to use a string to identify which line is the version (due to the way > it's parsing the output). > > Notice a theme here? > A few: libvirt's -help parsing is fragile. Libvirt is using an unsupported/unstable capabilities system, though it works acceptably in practice. Some others: Libvirt is a significant qemu consumer and provides value to the qemu project. qemu lacks a supported discoverable capabilities interface. And some facts: qemu 0.13 will not work with 95% of existing libvirt deployments. The 2 requested qemu reverts will have approx. 0 functional impact on plain qemu users. Can we evaluate these all together? Really, what's the harm in reverting these changes for 0.13, reapplying after the release is cut, and making a commitment to get some capabilities interface into 0.14? (and no libvirt appeasing -help/-version patches in the 0.14 cycle) - Cole