|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support |
Date: | Fri, 22 Jan 2010 17:14:34 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
On 01/22/2010 02:09 PM, Luiz Capitulino wrote:
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.
Just to further clarify, the mental model I have of capabilities is that they are things that affect the protocol itself. Additional features (new command options, new commands, new async messages) are things that are enabled/discovered in a different way.
Async messages themselves are a capability since it changes the protocol. Timestamps would be another capability and a new data type (like an uint64 type) would be a new capability.
I'm ok with that, Markus?
Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |