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

[Anthony Liguori <anthony@codemonkey.ws>]

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