[4/4] QMP: Update README file

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 <lcapitulino@redhat.com>
---
 QMP/README |   71 ++++++++++++++++++++++++++++++++++++++++-------------------
 1 files changed, 48 insertions(+), 23 deletions(-)

Luiz Capitulino <lcapitulino@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 <lcapitulino@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 <lcapitulino@redhat.com>

On Fri, 20 Aug 2010 18:04:57 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Luiz Capitulino <lcapitulino@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 <lcapitulino@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.

Yeah, looks better. Will resend.