qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	"aliguori@us.ibm.com" <aliguori@us.ibm.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/3] QMP: Introduce commands documentation
Date: Tue, 1 Jun 2010 10:49:50 -0300	[thread overview]
Message-ID: <20100601104950.0874a7c3@redhat.com> (raw)
In-Reply-To: <4C04B97C.5090408@siemens.com>

On Tue, 01 Jun 2010 09:40:44 +0200
Jan Kiszka <jan.kiszka@siemens.com> wrote:

> Stefan Hajnoczi wrote:
> > On Mon, May 31, 2010 at 6:43 PM, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > Hi Luiz,
> > 
> > I'm interested in QMP, have left some feedback.  As I get up to speed
> > with QMP my questions and suggestions will hopefully be useful.
> > Apologies in advance if any of my thoughts here are old news and have
> > been discussed elsewhere :).
> > 
> > I didn't see documentation on the errors that a command can encounter.
> >  Error documentation would be useful for commands where the client
> > needs to react by trying an alternative command.  If errors are opaque
> > or undocumented, then the client can't perform error recovery, they
> > can only log the error or prompt the user for help.
> > 
> >> @@ -113,6 +184,35 @@ Password: ********
> >>
> >>  @end table
> >>  ETEXI
> >> +SQMP
> >> +change
> >> +------
> >> +
> >> +Change a removable medium or VNC configuration.
> >> +
> >> +Arguments:
> >> +
> >> +- "device": device name (json-string)
> >> +- "target": filename or item (json-string)
> >> +- "arg": additional argument (json-string, optional)
> >> +
> >> +Examples:
> >> +
> >> +1. Change a removable medium
> >> +
> >> +-> { "execute": "change",
> >> +             "arguments": { "device": "ide1-cd0",
> >> +                            "target": "/srv/images/Fedora-12-x86_64-DVD.iso" } }
> >> +<- { "return": {} }
> >> +
> >> +2. Change VNC password
> >> +
> >> +-> { "execute": "change",
> >> +             "arguments": { "device": "vnc", "target": "password",
> >> +                            "arg": "foobar1" } }
> >> +<- { "return": {} }
> >> +
> >> +EQMP
> >>
> >>     {
> >>         .name       = "screendump",
> > 
> > For removable media is there a way to use, for instance, sheepdog, or
> > is the target strictly a file name?
> > 
> > Can the VNC password be removed when arg is the empty string or arg is
> > not present?
> > 
> >> @@ -532,6 +747,24 @@ STEXI
> >>  @findex cpu
> >>  Set the default CPU.
> >>  ETEXI
> >> +SQMP
> >> +cpu
> >> +---
> >> +
> >> +Set the default CPU.
> >> +
> >> +Arguments:
> >> +
> >> +- "index": the CPU's index (json-int)
> >> +
> >> +Example:
> >> +
> >> +-> { "execute": "cpu", "arguments": { "index": 0 } }
> >> +<- { "return": {} }
> >> +
> >> +Note: CPUs' indexes are obtained with the 'query-cpus' command.
> >> +
> >> +EQMP
> >>
> >>     {
> >>         .name       = "mouse_move",
> > 
> > I believe this is the per-monitor default cpu for memory dumping and
> > other per-cpu commands.  The concept of the default cpu makes sense
> > for an interactive monitor, humans don't want to type the cpu index
> > for each cpu-specific command.  For QMP it feels cleaner to have a cpu
> > argument for commands that are per-cpu.  As a newcomer I'm not sure of
> > the philosophy for QMP commands, 1:1 with monitor commands or as
> > appropriate for a JSON interface?
> 
> Makes some sense.
> 
> I've a simple patch in my queue that can be used to assign different
> arguments for QMP and HMP use. So we could add a 'cpu' argument to all
> those QMP commands that so far rely on the above mechanism.

 Nice.

> > If the QMP cpu command is supported in a QEMU release, can it be
> > phased out later?
> 
> Better avoid it being rolled out.

 After 0.13 no incompatible protocol change will be allowed.

> That said, first let us merge this documentation as baseline, then fix
> such things (including error documentation) on top of it.

 Exactly, the goal now is to describe the current protocol state.

  reply	other threads:[~2010-06-01 13:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-31 17:43 [Qemu-devel] [PATCH v4 0/3]: QMP: Commands doc Luiz Capitulino
2010-05-31 17:43 ` [Qemu-devel] [PATCH 1/3] monitor: Reorder info documentation Luiz Capitulino
2010-06-01 18:51   ` Anthony Liguori
2010-05-31 17:43 ` [Qemu-devel] [PATCH 2/3] QMP: Introduce commands documentation Luiz Capitulino
2010-05-31 20:22   ` Stefan Hajnoczi
2010-06-01  7:40     ` Jan Kiszka
2010-06-01 13:49       ` Luiz Capitulino [this message]
2010-06-01 14:09         ` Stefan Hajnoczi
2010-06-01 15:13       ` Anthony Liguori
2010-06-01 13:46     ` Luiz Capitulino
2010-06-01 16:10   ` [Qemu-devel] " Jan Kiszka
2010-06-01 17:27     ` Luiz Capitulino
2010-06-01 17:39       ` Jan Kiszka
2010-06-01 18:07         ` Anthony Liguori
2010-06-01 18:08           ` Jan Kiszka
2010-05-31 17:43 ` [Qemu-devel] [PATCH 3/3] Monitor: Drop QMP documentation from code Luiz Capitulino
  -- strict thread matches above, loose matches on Subject: below --
2010-05-19  1:32 [Qemu-devel] [PATCH v3 0/3]: QMP: Commands doc Luiz Capitulino
2010-05-19  1:32 ` [Qemu-devel] [PATCH 2/3] QMP: Introduce commands documentation 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=20100601104950.0874a7c3@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).