From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55643 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oq71q-0002pY-PP for qemu-devel@nongnu.org; Mon, 30 Aug 2010 12:16:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oq71p-0002Hu-63 for qemu-devel@nongnu.org; Mon, 30 Aug 2010 12:16:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20919) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq71o-0002HT-Uf for qemu-devel@nongnu.org; Mon, 30 Aug 2010 12:16:13 -0400 Date: Mon, 30 Aug 2010 13:16:02 -0300 From: Luiz Capitulino Message-ID: <20100830131602.2e846845@doriath> In-Reply-To: <4C7BD085.3020100@codemonkey.ws> References: <51ec99ce2db02aeb34ec6683a76895b4a127057d.1282886503.git.amit.shah@redhat.com> <20100827092945.GC22361@redhat.com> <4C77B209.6050902@codemonkey.ws> <20100827125827.GD22361@redhat.com> <20100827111507.5278eba3@doriath> <4C77D2EB.1030306@codemonkey.ws> <20100827130856.79869770@doriath> <4C780BD5.4030700@codemonkey.ws> <20100827162413.0235bcd0@doriath> <4C781412.6080303@codemonkey.ws> <4C7BCE19.30206@codemonkey.ws> <4C7BD085.3020100@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Should QMP be RPC to internal C interfaces? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu list , Markus Armbruster , agl@us.ibm.com, Amit Shah , Paolo Bonzini On Mon, 30 Aug 2010 10:38:45 -0500 Anthony Liguori wrote: > On 08/30/2010 10:28 AM, Anthony Liguori wrote: > > Having two interfaces guarantees failure. What's the separation > > between internal and external? Is qdev internal or external? > > Let me put it another way, compatibility cannot be an after thought. > > We need to think deeply about compatibility when we design our > interfaces and we're going to have to redesign interfaces with > compatibility in mind. It's a hard problem but it's solvable. Just > defaulting arguments in QMP doesn't do anything to improve compatibility. The point is: C compat sucks, QMP's doesn't. QMP will suck too if we direct map the two. You seem to think it's worth it, we don't. How do we solve that? > We cannot radically change our internal implementations and expect to > bridge it all in some special sauce code somewhere. > > This also suggests that we're going to have to practice deprecation to > evolve our APIs in a reasonable fashion. Deprecation should be mostly used for bad defined commands, not for simple extensions.