From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44589 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oq6Rd-00011r-5t for qemu-devel@nongnu.org; Mon, 30 Aug 2010 11:38:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oq6Rb-00040h-Ud for qemu-devel@nongnu.org; Mon, 30 Aug 2010 11:38:49 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:44774) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq6Rb-00040b-Pl for qemu-devel@nongnu.org; Mon, 30 Aug 2010 11:38:47 -0400 Received: by qwh5 with SMTP id 5so5206303qwh.4 for ; Mon, 30 Aug 2010 08:38:47 -0700 (PDT) Message-ID: <4C7BD085.3020100@codemonkey.ws> Date: Mon, 30 Aug 2010 10:38:45 -0500 From: Anthony Liguori MIME-Version: 1.0 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> In-Reply-To: <4C7BCE19.30206@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Markus Armbruster Cc: qemu list , Luiz Capitulino , agl@us.ibm.com, Amit Shah , Paolo Bonzini 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. 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. Regards, Anthony Liguori > Regards, > > Anthony Liguori