From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53209 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Op4CH-0004L9-Mn for qemu-devel@nongnu.org; Fri, 27 Aug 2010 15:02:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Op4CC-0004oc-JH for qemu-devel@nongnu.org; Fri, 27 Aug 2010 15:02:41 -0400 Received: from mail-qy0-f180.google.com ([209.85.216.180]:51424) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Op4CC-0004oP-FG for qemu-devel@nongnu.org; Fri, 27 Aug 2010 15:02:36 -0400 Received: by qyk31 with SMTP id 31so3324349qyk.4 for ; Fri, 27 Aug 2010 12:02:35 -0700 (PDT) Message-ID: <4C780BD5.4030700@codemonkey.ws> Date: Fri, 27 Aug 2010 14:02:45 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message 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> In-Reply-To: <20100827130856.79869770@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu list , Markus Armbruster , agl@us.ibm.com, Amit Shah , Paolo Bonzini 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. Having a sandbox doesn't really solve the fundamental problem of making sure the interface is consumable. >> 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. > 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. >> 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. >>>>> >>>>> >>>> >>>> >>> >>> >> >