|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED error message |
Date: | Fri, 27 Aug 2010 14:02:45 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
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 LiguoriBeyond 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.
[Prev in Thread] | Current Thread | [Next in Thread] |