[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH v3 2/3] qerror: Add a new MACHINE_STOPPED er

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: 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.


Anthony Liguori

void release_guest_balloon_stats(BalloonStatsRequest *req);


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.



[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]