From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60378 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdTI7-0007rf-En for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:24:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OdTI6-0005W8-76 for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:24:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7279) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdTI5-0005Vp-Te for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:24:46 -0400 Message-ID: <4C4DE0F7.5010305@redhat.com> Date: Mon, 26 Jul 2010 22:24:39 +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> <4C4DB7D4.3090405@redhat.com> <4C4DDC16.2000603@codemonkey.ws> In-Reply-To: <4C4DDC16.2000603@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 10:03 PM, Anthony Liguori wrote: > On 07/26/2010 11:29 AM, Avi Kivity wrote: >> On 07/26/2010 07:26 PM, Avi Kivity wrote: >>> >>>> The help output is *not* a supported interface. >>> >>> There is no supported, usable interface for this. >> >> Well actually, libvirt could probe this by starting qemu with cache=x >> for various x and seeing if it breaks. But the milk has already been >> spilled. > > So we're stuck with supporting the help output as an interface > forever? Even with a capabilities system, what about old versions of > libvirt? No, the rate of crap generation seems to increase all the time, we have to get rid of it eventually. If we provide a replacement, give a warning, wait some months for libvirt^Wusers to catch up, and throw away the deprecated feature, we can remove any feature we like. This is still a fast moving field and users to upgrade. Just not every week. > > At some point in time, old versions of libvirt are going to stop > working with new versions of QEMU because the help output changes. If > libvirt switches to something more reliable (like versioning), then > the gap is closed until there is a capabilities system. > > There will be a breakage though and we shouldn't pretend that taking > this patch does anything other than delay that breakage. There's a difference between - planned breakage with a warning ahead of time - unplanned breakage - unplanned breakage with unwillingness to fix -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.