Luiz Capitulino <lcapitul...@redhat.com> writes:
> A number of changes I prefer to do in one shot:
>
> - Fix example
> - Small clarifications
> - Add multiple monitors example
> - Add 'Development Process' section
>
> Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com>
> ---
> QMP/README | 71 ++++++++++++++++++++++++++++++++++++++++-------------------
> 1 files changed, 48 insertions(+), 23 deletions(-)
>
> diff --git a/QMP/README b/QMP/README
> index 35a80c7..b23f186 100644
> --- a/QMP/README
> +++ b/QMP/README
> @@ -7,60 +7,85 @@ Introduction
> The QEMU Monitor Protocol (QMP) allows applications to communicate with
> QEMU's Monitor.
>
> -QMP is JSON[1] based and has the following features:
> +QMP is JSON[1] based and currently has the following features:
>
> - Lightweight, text-based, easy to parse data format
> -- Asynchronous events support
> -- Stability
> +- Asynchronous messages support (ie. events)
> +- Capabilities Negotiation
>
> -For more information, please, refer to the following files:
> +For detailed information on QMP's usage, please, refer to the following
> files:
>
> o qmp-spec.txt QEMU Monitor Protocol current specification
> -o qmp-commands.txt QMP supported commands
> +o qmp-commands.txt QMP supported commands (auto-generated at build-time)
> o qmp-events.txt List of available asynchronous events
>
> There are also two simple Python scripts available:
>
> -o qmp-shell A shell
> -o vm-info Show some information about the Virtual Machine
> +o qmp-shell A shell
> +o vm-info Show some information about the Virtual Machine
> +
> +IMPORTANT: It's strongly recommended to read the 'Stability Considerations'
> +section in the qmp-commands.txt file before making any serious use of QMP.
> +
>
> [1] http://www.json.org
>
> Usage
> -----
>
> -To enable QMP, QEMU has to be started in "control mode". There are
> -two ways of doing this, the simplest one is using the the '-qmp'
> -command-line option.
> +To enable QMP, you need a QEMU monitor instance in "control mode". There are
> +two ways of doing this.
> +
> +The simplest one is using the '-qmp' command-line option. The following
> +example makes QMP available on localhost port 4444:
>
> -For example:
> + $ qemu [...] -qmp tcp:localhost:4444,server
>
> -$ qemu [...] -qmp tcp:localhost:4444,server
> +However, in order to have more complex combinations, like multiple monitors,
> +the '-mon' command-line option should be used along with the '-chardev' one.
> +For instance, the following example creates one user monitor on stdio and one
> +QMP monitor on localhost port 4444.
>
> -Will start QEMU in control mode, waiting for a client TCP connection
> -on localhost port 4444.
> + $ qemu [...] -chardev stdio,id=mon0 -mon chardev=mon0,mode=readline \
> + -chardev socket,id=mon1,host=localhost,port=4444,server \
> + -mon chardev=mon1,mode=control
>
> -It is also possible to use the '-mon' command-line option to have
> -more complex combinations. Please, refer to the QEMU's manpage for
> -more information.
> +Please, refer to QEMU's manpage for more information.
>
> Simple Testing
> --------------
>
> -To manually test QMP one can connect with telnet and issue commands:
> +To manually test QMP one can connect with telnet and issue commands by hand:
>
> $ telnet localhost 4444
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> -{"QMP": {"version": {"qemu": "0.12.50", "package": ""}, "capabilities": []}}
> +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 13, "major": 0},
> "package": ""}, "capabilities": []}}
Doesn't this belong into 2/4?
> { "execute": "qmp_capabilities" }
> {"return": {}}
> { "execute": "query-version" }
> -{"return": {"qemu": "0.12.50", "package": ""}}
> +{"return": {"qemu": {"micro": 50, "minor": 13, "major": 0}, "package": ""}}
This too.
Doubt it's worth a respin, though.
> +
> +Development Process
> +-------------------
> +
> +When changing QMP's interface (by adding new commands, events or modifying
> +existing ones) it's mandatory to update the relevant documentation, which is
> +one (or more) of the files listed in the 'Introduction' section*.
> +
> +Also, it's strongly recommended to send the documentation patch first, before
> +doing any code change. This is so because:
> +
> + 1. Avoids the code dictating the interface
> +
> + 2. It's very likely that the interface will change during review, updating
> + the code at the same time might be a big waste of time
"Very likely" sounds a bit discouraging, doesn't it? What about
2. Review can improve your interface. Letting that happen before
you implement it can save you work.
> +
> +* The qmp-commands.txt file is generated from the qemu-monitor.hx one, which
> + is the file that should be edited.
>
> -Contact
> --------
> +Homepage
> +--------
>
> http://www.linux-kvm.org/page/MonitorProtocol
> -Luiz Fernando N. Capitulino <lcapitul...@redhat.com>
