From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56617 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdTDZ-0005bQ-LK for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:20:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OdTDY-0004sT-8Z for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:20:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45227) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdTDY-0004sM-1s for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:20:04 -0400 Message-ID: <4C4DDFDC.3000608@redhat.com> Date: Mon, 26 Jul 2010 22:19:56 +0300 From: Avi Kivity 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> In-Reply-To: <4C4DDB25.90000@codemonkey.ws> 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: Anthony Liguori Cc: qemu-devel@nongnu.org, Markus Armbruster , Bruce Rogers On 07/26/2010 09:59 PM, Anthony Liguori wrote: >>> If libvirt is going to parse -help output, they should do a better >>> job at it. I can't expect QEMU developers to have detailed >>> knowledge of how libvirt parses the help output to ensure that we >>> don't break their code. >> >> Correct. libvirt could have done much better parsing. qemu >> developers are not familiar with libvirt code. But is there a >> problem in accepting the patch that rearranges the output? > > > What if another tool is parsing -help output? Then we have an even bigger problem. As for now, we have a manageable problem that this patch solves. Let's apply this workaround to fix the one real problem we know about, and work towards documented capability reporting to make sure this doesn't hit us in the future when we have more users. > Is what we are supporting just what libvirt expects there to be or > what any tool out there expects there to be? 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 far as I can tell, it's just as good for a user, and better for >> libvirt, so there are no drawbacks to accepting the patch? > > It's not. Our help output is unreadable. The (artificial) > restrictions we're putting ourselves with respect to the help output > prevents it from being improved. Are you saying " [,cache=writethrough|writeback|unsafe|none][,format=f]\n" is more readable than " [,cache=writethrough|writeback|none|unsafe][,format=f]\n" ? if so I disagree. If you say our help output is in general unreadable, then this has nothing to do with this patch. Implementing a capabilities system is more important than improving help output readability, let's to this first and then rewrite the help output in Shakespearean glory. >>> >>> Version is entirely reliable for detecting whether -drive supports >>> cache. >> >> It's not a reliable interface for detecting features in the face of >> backports. > > Backports are such a special case. Honestly, we're talking about RHEL > and it's trivially easy for libvirt to just special case RHEL. As it happens the patch came from a Novell employee, so it isn't about RHEL. I applaud your choice of enterprise operating systems, however. Regardless, outside of Windows users qemu will mostly be consumed via distribution branches, with different levels of backport happiness. We should recognize that and work with it, not against it. >> >> I don't see what we gain by not doing this. > > We're losing the ability to make *any* change to our help system by > encouraging it to be used in this fashion. If we could point libvirt towards a better way of doing things (not a better regexp, which could just break under different circumstances; a supported interface) I'd agree. Go RTFM chapter-this-or-that and don't bother me no more. But we can't. >> If you want libvirt to do the right thing, provide a proper >> capabilities interface. Using the version has its downsides as much >> as the help text. > > That's simply not the case. Please, provide an actual example where > version is not reliable and backports aren't trivially easy to detect. t=0 starting point, cache=unsafe is unknown t=1 qemu upstream adds cache=unknown t=2 libvirt adds support for cache=unsafe, releases t=3 evil distro backports cache=unsafe, releases qemu-kvm-1.2.3.4 t=4 user tries libvirt from t=2 with qemu from t=3, cache=unsafe not detected version numbers force a libvirt update every time a feature is backported. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.