qemu-devel
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support
Date: Mon, 25 Jan 2010 15:29:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Luiz Capitulino <address@hidden> writes:

> On Fri, 22 Jan 2010 12:05:19 -0600
> Anthony Liguori <address@hidden> 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.
>
>  To summarize (after a IRC talk): async messages are considered a
> capability and should be enabled during the negotiation phase but
> the masking of particular messages are not and can be done at
> any time after the negotiation phase.
>
>  I'm ok with that, Markus?

I agree with Anthony that async message masking doesn't really affect
the protocol proper.  We could pretend it does so we can let protocol
capability negotiation (which we need anyway) cover it.  But I'm
certainly fine with keeping it separate.

Whether we call it protocol or not, the question whether we should
permit changing the masks at any time is valid, I think.  Permitting it
adds a bit of conceptual complexity, as a command disabling reporting of
an event can race with the event.  But that's just giving clients some
more rope.  I'm fine with that.




reply via email to

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