From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38395 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oq6He-0004lF-6j for qemu-devel@nongnu.org; Mon, 30 Aug 2010 11:28:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oq6Hc-0002J9-S2 for qemu-devel@nongnu.org; Mon, 30 Aug 2010 11:28:30 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:36180) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oq6Hc-0002J4-Nu for qemu-devel@nongnu.org; Mon, 30 Aug 2010 11:28:28 -0400 Received: by qwh5 with SMTP id 5so5196370qwh.4 for ; Mon, 30 Aug 2010 08:28:27 -0700 (PDT) Message-ID: <4C7BCE19.30206@codemonkey.ws> Date: Mon, 30 Aug 2010 10:28:25 -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> In-Reply-To: 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 09:52 AM, Markus Armbruster wrote: >> Because it's too easy to get it wrong in QEMU. Here's the rationale. >> >> If I can't trivially call a QMP function in C, then I'm not going to >> use QMP functions within QEMU. I'm not going to create an embedded >> JSON string just to call a function with three integer arguments. >> > Yes, an internal interface is better done in idiomatic C, not with JSON > strings. > > >> Yes, if we need to do that, we can create a C API that both the QMP >> interface uses and we also use internally but why? All that does is >> introduce the chance that the C API will have more features than the >> QMP interface. >> > Why is that bad? > > Internal and external interfaces have very different tradeoffs. > > An internal interface should eschew backward compatibility and embrace > change. > > An external interface needs to be stable, yet extensible. > Nope. The internal interface should be the external interface. Otherwise, the external interface is going to rot. > It's therefore advisable to separate the two. Otherwise the internal > interface gets bogged down with undue compatibility considerations > (backward& forward), or the external interface suffers unnecessary > churn. > > When we designed QMP, we took special care to make it support compatible > evolution. We consciously made it a proper protocol, not RPC to > internal C interfaces. Are you proposing we go back to square one and > reargue the basics of QMP? > All the pretty JSON interfaces don't matter if we're not exposing a useful API. We're trying to do too much. We've been more or less completing ignoring the problem of creating a useful API for users to consume. We need to simplify. We simplify by reducing scope. Of the things that are important, a useful API is more important than whether it maps to your favorite dynamic language in an elegant way. > No, the problem we suffer today is that we didn't design the external > interface properly above the level of basic protocol. We took a > shortcut and converted existing monitor commands. We've since > discovered we don't like that approach. > > Instead of giving up on protocol design without even trying and just > expose whatever internal interfaces strike us as useful via RPC, let's > design the external interface properly. > What does that even mean? How do you describe the external interface properly? It's a hell of a lot simpler to design the external interface as a C API, and then to implement the external interface as a C API. Why make life harder than that? >> I think it's a vitally important requirement that all future QMP >> functions have direct mappings to a C interface. >> > Why? > So that we can consume those APIs within QEMU. >> The long term goal >> should be for that interface to be used by all of the command line >> arguments, SDL, and the human monitor. If those things only relied on >> a single API and we exposed that API via QMP, than we would have an >> extremely useful interface. >> > Yes, command line, human monitor and QMP should use internal interfaces > to do the real work, thus separate the real work neatly from > interface-specific stuff like parsing text. > > No, that doesn't mean we should expose internal interfaces via RPC. > Having two interfaces guarantees failure. What's the separation between internal and external? Is qdev internal or external? Regards, Anthony Liguori