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<lcapitul...@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
