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

[Anthony Liguori]

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<address@hidden>
> >
> > 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