From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46261 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Op60x-0002wX-QG for qemu-devel@nongnu.org; Fri, 27 Aug 2010 16:59:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Op60w-0001ST-8W for qemu-devel@nongnu.org; Fri, 27 Aug 2010 16:59:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55831) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Op60v-0001SE-W6 for qemu-devel@nongnu.org; Fri, 27 Aug 2010 16:59:06 -0400 Date: Fri, 27 Aug 2010 17:58:57 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message Message-ID: <20100827175857.03703632@doriath> In-Reply-To: <4C781412.6080303@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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 list , Markus Armbruster , agl@us.ibm.com, Amit Shah , Paolo Bonzini On Fri, 27 Aug 2010 14:37:54 -0500 Anthony Liguori wrote: > On 08/27/2010 02:24 PM, Luiz Capitulino wrote: > > > >> I don't see how 0.13.0 is going to get releases with anything but the > >> current behavior. It's unfortunate but we're too delayed and can't > >> afford a change like this this late in the game. > >> > >> In terms of the stable branch, the least disruptive thing would be a > >> timeout. > >> > > Okay. > > > > > >>> I think we have agreed on the internal interfaces approach. My only > >>> concern is whether this will conflict when extending the wire protocol > >>> (eg. adding new arguments to existing commands). Not a problem if the > >>> C API is not stable, of course. > >>> > >>> > >> We don't do that. It's a recipe for disaster. QEMU isn't written in > >> Python and if we try to module our interfaces are if we were a Python > >> library, we're destined to fail. > >> > > You mean we don't do simple protocol extensions? > > > > So, if we need an new argument to an existing command, we add a new > > command instead? Just because QEMU is not written in Python? > > > > 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. ... And as a QMP client I don't see the point in having to use a new command just because a new argument was needed. The language QEMU is written is also unimportant. The wire format is all I see and it's language independent. > 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? I mean, what would stop us on extending QMP when the C interface is also extended? Examples? At first, this seems a good middle ground to me: QMP is implemented on top of the C API and the JSON stuff is limited to QMP. Of course that C API functions returning structured data will have to create and return qobjects. But that's needed even with the direct mapping. > If we don't use these functions in QEMU, then how do we know that these > functions have reasonable semantics? This is exactly the problem we > suffer today. We have internal APIs that do reasonable things but > everything that deals with QMP is a special case. That creates too many > opportunities to get things wrong. > > I think it's a vitally important requirement that all future QMP > functions have direct mappings to a C interface. 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. I agree, I just think an indirect mapping would be more beneficial to QMP clients.