QMP: Update spec file

- Remove "draft" status
- Change default success response to be json-object
- Change error and event data member to be a json-object
- Update examples
- Add new section "Compatibility Considerations"
- Other fixes and clarifications

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This commit is contained in:
Luiz Capitulino 2009-12-18 13:25:03 -02:00 committed by Anthony Liguori
parent 052f1b9be5
commit 940489824e

View File

@ -1,4 +1,4 @@
QEMU Monitor Protocol Draft Specification - Version 0.1 QEMU Monitor Protocol Specification - Version 0.1
1. Introduction 1. Introduction
=============== ===============
@ -27,9 +27,9 @@ the JSON standard:
http://www.ietf.org/rfc/rfc4627.txt http://www.ietf.org/rfc/rfc4627.txt
For convenience, json-objects mentioned in this document will have its members For convenience, json-object members and json-array elements mentioned in
in a certain order. However, in real protocol usage json-objects members can this document will be in a certain order. However, in real protocol usage
be in ANY order, thus no particular order should be assumed. they can be in ANY order, thus no particular order should be assumed.
2.1 General Definitions 2.1 General Definitions
----------------------- -----------------------
@ -85,12 +85,13 @@ without errors.
The format is: The format is:
{ "return": json-value, "id": json-value } { "return": json-object, "id": json-value }
Where, Where,
- The "return" member contains the command returned data, which is defined - The "return" member contains the command returned data, which is defined
in a per-command basis or "OK" if the command does not return data in a per-command basis or an empty json-object if the command does not
return data
- The "id" member contains the transaction identification associated - The "id" member contains the transaction identification associated
with the command execution (if issued by the Client) with the command execution (if issued by the Client)
@ -102,7 +103,7 @@ completed because of an error condition.
The format is: The format is:
{ "error": { "class": json-string, "data": json-value, "desc": json-string }, { "error": { "class": json-string, "data": json-object, "desc": json-string },
"id": json-value } "id": json-value }
Where, Where,
@ -110,7 +111,7 @@ The format is:
- The "class" member contains the error class name (eg. "ServiceUnavailable") - The "class" member contains the error class name (eg. "ServiceUnavailable")
- The "data" member contains specific error data and is defined in a - The "data" member contains specific error data and is defined in a
per-command basis, it will be an empty json-object if the error has no data per-command basis, it will be an empty json-object if the error has no data
- The "desc" member is a human-readable error message. Clients should - The "desc" member is a human-readable error message. Clients should
not attempt to parse this message. not attempt to parse this message.
- The "id" member contains the transaction identification associated with - The "id" member contains the transaction identification associated with
the command execution (if issued by the Client) the command execution (if issued by the Client)
@ -127,7 +128,7 @@ to the Client at any time. They are called 'asynchronous events'.
The format is: The format is:
{ "event": json-string, "data": json-value, { "event": json-string, "data": json-object,
"timestamp": { "seconds": json-number, "microseconds": json-number } } "timestamp": { "seconds": json-number, "microseconds": json-number } }
Where, Where,
@ -135,7 +136,7 @@ The format is:
- The "event" member contains the event's name - The "event" member contains the event's name
- The "data" member contains event specific data, which is defined in a - The "data" member contains event specific data, which is defined in a
per-event basis, it is optional per-event basis, it is optional
- The "timestamp" member contains the exact time of when the event ocurred - The "timestamp" member contains the exact time of when the event occurred
in the Server. It is a fixed json-object with time in seconds and in the Server. It is a fixed json-object with time in seconds and
microseconds microseconds
@ -157,19 +158,20 @@ S: {"QMP": {"capabilities": []}}
--------------------------- ---------------------------
C: { "execute": "stop" } C: { "execute": "stop" }
S: {"return": "OK"} S: {"return": {}}
3.3 KVM information 3.3 KVM information
------------------- -------------------
C: {"execute": "query-kvm", "id": "example"} C: { "execute": "query-kvm", "id": "example" }
S: {"return": "enabled", "id": "example"} S: {"return": {"enabled": true, "present": true}, "id": "example"}
3.4 Parsing error 3.4 Parsing error
------------------ ------------------
C: { "execute": } C: { "execute": }
S: {"error": {"class": "JSONParsing", "data": {}}} S: {"error": {"class": "JSONParsing", "desc": "Invalid JSON syntax", "data":
{}}}
3.5 Powerdown event 3.5 Powerdown event
------------------- -------------------
@ -177,19 +179,25 @@ S: {"error": {"class": "JSONParsing", "data": {}}}
S: {"timestamp": {"seconds": 1258551470, "microseconds": 802384}, "event": S: {"timestamp": {"seconds": 1258551470, "microseconds": 802384}, "event":
"POWERDOWN"} "POWERDOWN"}
4. Notes to Client implementors 4. Compatibility Considerations
------------------------------- --------------------------------
4.1 It is recommended to always start the Server in pause mode, thus the In order to achieve maximum compatibility between versions, Clients must not
Client is able to perform any setup procedure without the risk of assume any particular:
race conditions and related problems
4.2 It is recommended to always check the capabilities json-array, issued - Size of json-objects or length of json-arrays
with the greeting message, at connection time - Order of json-object members or json-array elements
- Amount of errors generated by a command, that is, new errors can be added
to any existing command in newer versions of the Server
4.3 Json-objects or json-arrays mentioned in this document are not fixed Additionally, Clients should always:
and no particular size or number of members/elements should be assumed.
New members/elements can be added at any time.
4.4 No particular order of json-objects members should be assumed, they - Check the capabilities json-array at connection time
can change at any time - Check the availability of commands with 'query-commands' before issuing them
5. Recommendations to Client implementors
-----------------------------------------
5.1 The Server should be always started in pause mode, thus the Client is
able to perform any setup procedure without the risk of race conditions
and related problems