From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56698 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Op4XI-0007ir-Eu for qemu-devel@nongnu.org; Fri, 27 Aug 2010 15:24:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Op4XH-0006ut-9E for qemu-devel@nongnu.org; Fri, 27 Aug 2010 15:24:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1025) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Op4XH-0006um-09 for qemu-devel@nongnu.org; Fri, 27 Aug 2010 15:24:23 -0400 Date: Fri, 27 Aug 2010 16:24:13 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message Message-ID: <20100827162413.0235bcd0@doriath> In-Reply-To: <4C780BD5.4030700@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> 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:02:45 -0500 Anthony Liguori wrote: > On 08/27/2010 11:08 AM, Luiz Capitulino wrote: > >> It's trying to plug a sieve with a band-aid. It's certainly an > >> "improvement" but it's of question utility looking at the bigger picture. > >> > > Are you talking about the testing namespace idea? It doesn't have anything > > to do with balloon or how our interfaces are built. It would be just a way > > to play with commands that has been converted to QMP but are not available > > because they're not stable yet (eg. Jan's device_show). > > > > My point is that we shouldn't build any QMP APIs and we definitely > shouldn't try to QMP-ize monitor commands. > > Instead, we should design logical C APIs that we could consume within > QEMU that we think we can support long term and then expose those over QMP. Comments on the Python comment below. > Having a sandbox doesn't really solve the fundamental problem of making > sure the interface is consumable. It doesn't and it shouldn't. It's just a way to test commands that might not be stable yet. A very minor feature, anyway. > >> Balloon is a perfect example of where what we really need to do is build > >> interface interfaces that make sense, and then expose them in QMP. > >> > > Main question is: can we drop the stats the way they are today to do the > > Right Thing for 0.14 or not? > > > > 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? > >> What's a reasonable C-level API to query statistics that potentially may > >> never return? Building in a timeout is something of a crappy API > >> because it puts policy deep in the API that is trivial to implement > >> elsewhere. What you'd probably do is something like: > >> > >> BalloonStatsRequest *query_guest_balloon_stats(CompletionCallback *cb, > >> void *opaque); > >> int cancel_guest_balloon_stats(BalloonStatsRequest *req); > >> > > Shouldn't the API provide a general cancel method? All functions that > > talk to the guest will need one. > > > > See next proposal. There's no cancel but I'd argue it's not needed. > You don't care if the request succeeds or fails so there's no point in > cancelling it. Cancellation only works best when a request has a > discrete life cycle but in the case of requesting a guest to update > stats, there is not really a well define dstart and end. > > Regards, > > Anthony Liguori > > >> void release_guest_balloon_stats(BalloonStatsRequest *req); > >> > >> Regards, > >> > >> Anthony Liguori > >> > >> > >>>> > >>>> > >>>>> Beyond fixing that regression, I agree that this command is terminally > >>>>> flawed& we need to deprecate it& provide better specified new > >>>>> replacement(s). This seems like 0.14 work to me though. > >>>>> > >>>>> > >>>> Yup. > >>>> > >>>> > >>>> > >>>>> Regards, > >>>>> Daniel > >>>>> > >>>>> [1] I know that they could already suffer if there was a bug in qemu > >>>>> that prevented it responding, even if the guest was not being > >>>>> malicious/crashed. > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > > >