qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 00/11]: QMP feature negotiation support


From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC 00/11]: QMP feature negotiation support
Date: Fri, 22 Jan 2010 11:21:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

A few quick questions before I dive into the patches...

Luiz Capitulino <address@hidden> writes:

>  Feature negotiation allows clients to enable QMP capabilities they are
> interested in using. This allows QMP to envolve without breaking old clients.
>
>  A capability is a new QMP feature and/or protocol change which is not part of
> the core protocol as defined in the QMP spec.
>
>  Feature negotiation is implemented by defining a set of rules and adding
> mode-oriented support.
>
>  The set of rules are:
>
> o All QMP capabilities are disabled by default
> o All QMP capabilities must be advertised in the capabilities array
> o Commands to enable/disable capabilities must be provided
>
> NOTE: Asynchronous messages are now considered a capability.
>
>  Mode-oriented support adds the following to QMP:
>
> o Two modes: handshake and operational
> o By default all QMP Monitors start in handshake mode

"By default"?  Is there a way to start a QMP monitor in another mode?

> o In handshake mode only commands to query/enable/disable QMP capabilities are
>   allowed (there are few exceptions)

Note to self: check out the exception, and why we might want them.

> o Clients can switch to the operational mode at any time

Can they switch back?  I hope not.

> o In Operational mode most commands are allowed and QMP capabilities changes
>   made in handshake mode take effect
>
>  Also note that each QMP Monitor has its own mode state and set of 
> capabilities,
> this means that if QEMU is started with N QMP Monitors protocol setup done in
> one of them doesn't affect the others.
>
>  Session example:
>
> """
> {"QMP": {"capabilities": ["async messages"]}}
>
> { "execute": "query-qmp-mode" }
> {"return": {"mode": "handshake"}}

Why would clients want to query the mode?

> { "execute": "change", "arguments": { "device": "vnc", "target": "password", 
> "arg": "1234" } }
> {"error": {"class": "QMPInvalidModeCommad", "desc": "The issued command is 
> invalid in this mode", "data": {}}}

I'd treat this like a completely unknown command.

> { "execute": "async_msg_enable", "arguments": { "name": "STOP" } }
> {"return": {}}
>
> { "execute": "qmp_switch_mode", "arguments": { "mode": "operational" } }
> {"return": {}}

Do we envisage mode transitions other than handshake -> operational?

> { "execute": "query-qmp-mode" }
> {"return": {"mode": "operational"}}
>
> { "execute": "change", "arguments": { "device": "vnc", "target": "password", 
> "arg": "1234" } }
> {"return": {}}
> """
>
>  TODO:
>
> - Update the spec
> - Test more and fix some known issues
> - Improve the changelog a bit




reply via email to

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