qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
	lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
Date: Wed, 29 May 2013 10:13:42 +0200	[thread overview]
Message-ID: <20130529081341.GB3521@dhcp-200-207.str.redhat.com> (raw)
In-Reply-To: <51A4D63B.3040103@redhat.com>

Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
> On 05/28/2013 09:27 AM, Kevin Wolf wrote:
> > The QMP version is flagged with a __org.qemu.debug- prefix in order to
> > reinforce the statement that qemu-io is for testing and debugging only,
> > with no API guarantees.
> 
> Correct use of naming conventions.
> 
> Hmm, I wonder if the recent addition of an 'abort' action to
> 'transaction' should be renamed __org.qemu.debug-abort, to make it
> obvious that it is another case of a QMP command useful mainly for
> testing, and not real-life use.

Makes sense to me.

But first I'd like to get Luiz's ack for this, because I think I'm the
first one to use an __org.qemu prefix, and I'm the first one trying to
introduce a QMP command without API stability.

> > 
> > The HMP version is simply called 'qemu-io' for convenience.
> > 
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> 
> > +++ b/hmp-commands.hx
> > @@ -1551,6 +1551,22 @@ Removes the chardev @var{id}.
> >  ETEXI
> >  
> >      {
> > +        .name       = "qemu-io",
> > +        .args_type  = "device:B,command:s",
> > +        .params     = "[device] \"[command]\"",
> > +        .help       = "run a qemu-io command on a block device",
> > +        .mhandler.cmd = hmp_qemu_io,
> > +    },
> > +
> > +STEXI
> > +@item chardev_remove id
> > +@findex chardev_remove
> > +
> > +Removes the chardev @var{id}.
> 
> Is this the right documentation?

Obviously not. I find these files where you declare monitor commands
horribly confusing, and this is the result...

> > +++ b/qapi-schema.json
> > @@ -3618,3 +3618,19 @@
> >              '*cpuid-input-ecx': 'int',
> >              'cpuid-register': 'X86CPURegister32',
> >              'features': 'int' } }
> > +
> > +##
> > +# @__org.qemu.debug-qemu-io-command
> > +#
> > +# Execute a qemu-io command
> > +#
> > +# @device:  The block device on which the command should be executed
> > +#
> > +# @command: The command to execute
> > +#
> > +# Returns:  Nothing on success
> > +#
> > +# Since: 1.6 (testing and debugging use only, no API stability)
> > +##
> > +{ 'command': '__org.qemu.debug-qemu-io-command',
> > +  'data': {'device': 'str', 'command': 'str'} }
> 
> I would have asked that 'command' be an enum, except that we promise no
> API stability so there's no need to lock us into an enum that could be
> introspected :)  This command looks fine as-is.

Wouldn't even work because the command includes parameters and things.
This is really what you would type on the qemu-io command line. So a
typical example might look like:

{ "execute": "__org.qemu.debug-qemu-io-command", "arguments":
    { "device": "ide0-hd0", "command": "write -P 0x12 4M 512k" } }

There's nothing structured about it, but for testing and debugging this
should be good enough.

> > diff --git a/qmp-commands.hx b/qmp-commands.hx
> > index ffd130e..8682bea 100644
> > --- a/qmp-commands.hx
> > +++ b/qmp-commands.hx
> > @@ -2932,3 +2932,31 @@ Example:
> >  <- { "return": {} }
> >  
> >  EQMP
> > +
> > +    {
> > +        .name       = "__org.qemu.debug-qemu-io-command",
> > +        .args_type  = "device:s,command:s",
> > +        .mhandler.cmd_new = qmp_marshal_input___org_qemu_debug_qemu_io_command,
> > +    },
> > +
> > +
> > +SQMP
> > +__org.qemu.debug-qemu-io-command
> > +--------------------------------
> 
> Do we really need to have SQMP documentation of the command, or is
> listing of its handler sufficient?  In other words, if this is
> debug-only, can we just leave it undocumented instead of listing an
> example only to declare the example non-portable?

I don't mind either way. Luiz?

Kevin

  reply	other threads:[~2013-05-29  8:14 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 15:27 [Qemu-devel] [PATCH 00/16] Make qemu-io commands available in the monitor Kevin Wolf
2013-05-28 15:27 ` [Qemu-devel] [PATCH 01/16] qemu-io: Remove unused args_command Kevin Wolf
2013-05-28 16:18   ` Eric Blake
2013-05-28 15:27 ` [Qemu-devel] [PATCH 02/16] cutils: Support 'P' and 'E' suffixes in strtosz() Kevin Wolf
2013-05-28 16:29   ` Eric Blake
2013-05-28 15:27 ` [Qemu-devel] [PATCH 03/16] qemu-io: Make cvtnum() a wrapper around strtosz_suffix() Kevin Wolf
2013-05-28 16:42   ` Eric Blake
2013-05-28 15:27 ` [Qemu-devel] [PATCH 04/16] qemu-io: Handle cvtnum() errors in 'alloc' Kevin Wolf
2013-05-28 16:53   ` Eric Blake
2013-05-28 15:27 ` [Qemu-devel] [PATCH 05/16] qemu-io: Don't use global bs in command implementations Kevin Wolf
2013-05-28 15:37   ` Kevin Wolf
2013-05-28 17:02     ` Eric Blake
2013-06-05 12:28   ` Stefan Hajnoczi
2013-06-05 12:39     ` Kevin Wolf
2013-05-28 15:27 ` [Qemu-devel] [PATCH 06/16] qemu-io: Split off commands to qemu-io-cmds.c Kevin Wolf
2013-05-29 20:29   ` Eric Blake
2013-06-04 10:11     ` Kevin Wolf
2013-05-28 15:27 ` [Qemu-devel] [PATCH 07/16] qemu-io: Factor out qemuio_command Kevin Wolf
2013-05-29 21:11   ` Eric Blake
2013-06-05 12:33   ` Stefan Hajnoczi
2013-05-28 15:27 ` [Qemu-devel] [PATCH 08/16] qemu-io: Move 'help' function Kevin Wolf
2013-05-29 21:25   ` Eric Blake
2013-06-04 10:20     ` Kevin Wolf
2013-06-05 12:37   ` Stefan Hajnoczi
2013-05-28 15:27 ` [Qemu-devel] [PATCH 09/16] qemu-io: Move 'quit' function Kevin Wolf
2013-05-29 22:11   ` Eric Blake
2013-05-28 15:27 ` [Qemu-devel] [PATCH 10/16] qemu-io: Move qemu_strsep() to cutils.c Kevin Wolf
2013-05-29 22:12   ` Eric Blake
2013-05-28 15:27 ` [Qemu-devel] [PATCH 11/16] qemu-io: Move functions for registering and running commands Kevin Wolf
2013-05-30  2:27   ` Eric Blake
2013-06-05 12:42   ` Stefan Hajnoczi
2013-05-28 15:27 ` [Qemu-devel] [PATCH 12/16] qemu-io: Move command_loop() and friends Kevin Wolf
2013-05-28 15:27 ` [Qemu-devel] [PATCH 13/16] qemu-io: Move remaining helpers from cmd.c Kevin Wolf
2013-05-28 15:27 ` [Qemu-devel] [PATCH 14/16] qemu-io: Interface cleanup Kevin Wolf
2013-05-28 15:27 ` [Qemu-devel] [PATCH 15/16] qemu-io: Use the qemu version for -V Kevin Wolf
2013-05-28 15:27 ` [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor Kevin Wolf
2013-05-28 16:07   ` Eric Blake
2013-05-29  8:13     ` Kevin Wolf [this message]
2013-05-29 12:05       ` Eric Blake
2013-05-29 17:51       ` Luiz Capitulino
2013-06-04 10:08         ` Kevin Wolf
2013-06-04 12:40           ` Luiz Capitulino
2013-06-04 12:49             ` Kevin Wolf
2013-06-04 13:09               ` Luiz Capitulino
2013-06-05 13:02 ` [Qemu-devel] [PATCH 00/16] " Stefan Hajnoczi

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=20130529081341.GB3521@dhcp-200-207.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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).