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

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/24/2010 04:34 AM, 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.

To be honest, I don't think there's really a need to mask individual 
messages.  A client can always ignore messages it doesn't care about.  
There is no side effect of receiving a message so there is no functional 
implication of receiving messages you don't care about.

The only time it would matter is if we had a really high volume of 
messages.  I'd suggest waiting until a message is introduced that could 
potentially have a high rate and then implement a mechanism to mask it.  
For now, it just adds unnecessary complexity.

Regards,

Anthony Liguori