From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46790 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdTbv-0006Kb-Cg for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:45:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OdTbu-00083v-8n for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:45:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14265) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdTbu-00083h-1s for qemu-devel@nongnu.org; Mon, 26 Jul 2010 15:45:14 -0400 From: Juan Quintela In-Reply-To: <4C4DE0F7.5010305@redhat.com> (Avi Kivity's message of "Mon, 26 Jul 2010 22:24:39 +0300") 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> <4C4DE0F7.5010305@redhat.com> Date: Mon, 26 Jul 2010 21:43:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH] move 'unsafe' to end of caching modes in help Reply-To: quintela@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Bruce Rogers , qemu-devel@nongnu.org, Markus Armbruster Avi Kivity wrote: > 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 Fully agree here. We have lots of (mis)features that we want to remove. But one thing is just remove them, and another to remove something before we create a valid alternative. I am all for: docs/deprecated-features.txt And having there things that will be removed and when. Later, Juan.