Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/24/2010 05:07 AM, Jamie Lokier wrote:
> Avi Kivity wrote:
>    
>> On 01/22/2010 08:05 PM, Anthony Liguori wrote:
>>      
>>> On 01/21/2010 03:09 PM, Luiz Capitulino wrote:
>>>        
>>>> This commit disables asynchronous messages by default and
>>>> introduces two new QMP commands: async_msg_enable and
>>>> async_msg_disable.
>>>>
>>>> Each QMP Monitor has its own set of asynchronous messages,
>>>> so for example, if QEMU is run with two QMP Monitors async
>>>> messages setup in one of them doesn't affect the other.
>>>>
>>>> To implement this design a bitmap is introduced to the
>>>> Monitor struct, each async message is represented by one bit.
>>>>
>>>> Signed-off-by: Luiz Capitulino<lcapitulino@redhat.com>
>>>>          
>>> Ah, I see I was a little confused.
>>>
>>> I'd suggest making async message masking an independent mechanism.
>>> Capabilities should strictly deal with protocol changes, not feature
>>> details.
>>>
>>> For instance, protocol timestamps are something would reasonable
>>> considered a capability.  Extended data types would be a capability.
>>>
>>> Another way to look at it, is that if you're writing a client library,
>>> the capability negotiation should be entirely invisible to the end API
>>> user.
>>>        
>> I agree with that, but we can look at async messages as a baseline
>> protocol capability (thus no negotiation required), and the new command
>> only enabled individual messages.
>>      
> I'd like to be able to connect and be sure not to receive any async
> messages, from simple scripts with simple output parsing.
>    

You can't have simple output parsing with QMP.  You need a full JSON 
stack.  The simplest script would be a python script that uses the 
builtin json support.  Having async messages means that you'll have to 
loop on recv in order make sure that the response is a command response 
vs. an async message.  It's just a few lines more of code so I have a 
hard time believing it's really a problem.

But what you probably want is a python QMP library and that would mean 
you wouldn't need the few more lines of code.

> If async messages can only be received as a result of commands which
> trigger individual messages, that will be achieved.
>
> But it would be a nice little bonus if disabling async messages caused
> all slow commands to be synchronous - that is, the async result
> message becomes the command's synchronous result.
>    

I know what you're getting at but I think it's the wrong target for 
QMP.  The goal is not to allow simple, hacky clients, but to provide a 
robust management API.  It should not be difficult to use, but parsing 
it in a shell with awk is not a requirement in my mind :-)

Regards,

Anthony Liguori