From: Markus Armbruster <armbru@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com
Subject: Re: [Qemu-devel] [RFC 00/11]: QMP feature negotiation support
Date: Fri, 22 Jan 2010 11:21:22 +0100 [thread overview]
Message-ID: <m3pr52san1.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <1264108180-3666-1-git-send-email-lcapitulino@redhat.com> (Luiz Capitulino's message of "Thu, 21 Jan 2010 19:09:29 -0200")
A few quick questions before I dive into the patches...
Luiz Capitulino <lcapitulino@redhat.com> 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
next prev parent reply other threads:[~2010-01-22 10:21 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 21:09 [Qemu-devel] [RFC 00/11]: QMP feature negotiation support Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 01/11] QMP: Initial mode-oriented bits Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 02/11] QMP: Introduce 'query-qmp-mode' command Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 03/11] QError: Add QMP mode-oriented errors Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 04/11] QMP: Introduce qmp_switch_mode command Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 05/11] QMP: advertise asynchronous messages Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 06/11] QMP: Array-based async messages Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 07/11] QError: New QERR_ASYNC_MSG_NOT_FOUND Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 08/11] QMP: Asynchronous messages enable/disable support Luiz Capitulino
2010-01-22 18:05 ` Anthony Liguori
2010-01-22 20:09 ` Luiz Capitulino
2010-01-22 23:14 ` Anthony Liguori
2010-01-25 14:29 ` Markus Armbruster
2010-01-25 14:33 ` Avi Kivity
2010-01-25 15:11 ` Luiz Capitulino
2010-01-24 10:34 ` Avi Kivity
2010-01-24 11:07 ` Jamie Lokier
2010-01-24 15:35 ` Anthony Liguori
2010-01-24 18:35 ` Jamie Lokier
2010-01-25 11:49 ` Luiz Capitulino
2010-01-25 14:15 ` Markus Armbruster
2010-01-25 14:22 ` Luiz Capitulino
2010-01-24 14:04 ` Anthony Liguori
2010-01-24 14:17 ` Avi Kivity
2010-01-24 14:19 ` Anthony Liguori
2010-01-25 12:02 ` Luiz Capitulino
2010-01-24 10:36 ` [Qemu-devel] " Avi Kivity
2010-01-25 13:14 ` Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 09/11] Monitor: Introduce find_info_cmd() Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 10/11] QError: New QERR_QMP_INVALID_MODE_COMMAND Luiz Capitulino
2010-01-21 21:09 ` [Qemu-devel] [PATCH 11/11] QMP: Enable feature negotiation support Luiz Capitulino
2010-01-22 10:21 ` Markus Armbruster [this message]
2010-01-22 12:09 ` [Qemu-devel] [RFC 00/11]: QMP " Luiz Capitulino
2010-01-22 14:00 ` Markus Armbruster
2010-01-22 18:00 ` Anthony Liguori
2010-01-25 14:33 ` Markus Armbruster
2010-01-26 11:53 ` Luiz Capitulino
2010-01-26 12:57 ` Jamie Lokier
2010-01-26 13:45 ` Luiz Capitulino
2010-01-26 14:29 ` Daniel P. Berrange
2010-01-26 15:57 ` Jamie Lokier
2010-01-26 16:21 ` Luiz Capitulino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3pr52san1.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.