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.
next prev parent 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).