qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Amos Kong <akong@redhat.com>
Cc: aliguori@us.ibm.com, lcapitulino@redhat.com,
	qemu-devel@nongnu.org, jyang@redhat.com,
	mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH] monitor: introduce query-config-schema
Date: Fri, 19 Apr 2013 06:39:36 -0600	[thread overview]
Message-ID: <51713B08.1050504@redhat.com> (raw)
In-Reply-To: <1366365123-5412-1-git-send-email-akong@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4463 bytes --]

On 04/19/2013 03:52 AM, Amos Kong wrote:
> Libvirt doesn't have a stable way to know option support
> detail. This patch introdued a new qmp command to query
> configuration schema information. hmp command isn't added.

Agreed; HMP is not needed: by the time you can connect to a human
monitor, you've already invoked the command line, and humans can read
-help.  It's just libvirt (and other management apps) that need a
machine-parseable alternative to -help.

> 
> Signed-off-by: Amos Kong <akong@redhat.com>
> CC: Osier Yang <jyang@redhat.com>
> CC: Anthony Liguori <aliguori@us.ibm.com>
> ---
> Reposted this patch: https://www.redhat.com/archives/libvir-list/2013-January/msg01656.html
> ---
>  qapi-schema.json       |   26 ++++++++++++++++++++++++++
>  qemu-options-wrapper.h |   16 ++++++++++++++++
>  qmp-commands.hx        |   32 ++++++++++++++++++++++++++++++++
>  qmp.c                  |   36 ++++++++++++++++++++++++++++++++++++
>  4 files changed, 110 insertions(+), 0 deletions(-)

In addition to Osier's review,

> +##
> +# @ConfigSchemaInfo:
> +#
> +# Configration schema information.
> +#
> +# @option: option name
> +#
> +# @config-schema: configuration schema string of one option

Any more details about the typical contents of this string?  Is it
supposed to be machine-parseable, or is it merely a human-readable
replay of -help text where the only machine-parseable aspect is whether
a particular @option name exists?

> +#
> +# Since 1.5
> +##
> +{ 'type': 'ConfigSchemaInfo', 'data': {'option': 'str', 'config-schema': 'str'} }
> +
> +##
> +# @query-config-schema
> +#
> +# Query configuration schema information of options
> +#
> +# @option: #optional option name

I don't know that may existing query-* commands support optional
arguments for filtering; but it seems like a nice enough thing to provide.

> +#
> +# Returns: @ConfigSchemaInfo list
> +#
> +# Since 1.5
> +##
> +{'command': 'query-config-schema', 'data': {'*option': 'str'}, 'returns': ['ConfigSchemaInfo']}

Long line; it might be worth wrapping this similar to what other
commands have done.

> +SQMP
> +query-config-schema
> +------------
> +
> +Show configuration schema.
> +
> +Return configuration schema of one option, if no option is assigned,
> +will return configuration schema of all options.
> +
> +- "option": option name
> +- "config-schema": configuration schema string of one option
> +
> +Example:
> +-> {"execute": "query-config-schema", "arguments" : {"option": "boot"}}
> +<- {"return": [
> +     {"config-schema": "-boot [order=drives][,once=drives][,menu=on|off]\n
> +        [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time][,strict=on|off]\n
> +	'drives': floppy (a), hard disk (c), CD-ROM (d), network (n)\n
> +	'sp_name': the file's name that would be passed to bios as logo picture, if menu=on\n
> +	'sp_time': the period that splash picture last if menu=on, unit is ms\n
> +	'rb_timeout': the timeout before guest reboot when boot failed, unit is ms\n",

Ah, the example makes it clear - this is human-readable text from -help
output, and not something that is further machine-parseable.  Which
means that if we have an existing command line version in one qemu
release, and the next qemu release adds more features to that option, we
have no reliable way (other than string-scraping) to detect that new
feature of the existing option.  Can we do any better?

I was expecting more of a JSON representation of the
QEMUOptionParameter[] used to parse a given option - THAT would be
machine-parseable, and would also let us know when an option has learned
more arguments in a newer qemu version.  But it is also something that
can be added later (we've already decided that query-* commands can add
output fields to their dictionary as needed).

The name 'config-schema' sounds like it is machine-parseable; can we use
a more descriptive name such as 'help-text' that makes it obvious what
you are really providing?

> +++ b/qmp.c
> @@ -24,6 +24,9 @@
>  #include "hw/qdev.h"
>  #include "sysemu/blockdev.h"
>  #include "qom/qom-qobject.h"
> +#include "qemu-options.h"
> +#include "net/net.h"

What does net/net.h have to do with anything?

Overall, looks quite useful, and it is worth getting into 1.5.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

  parent reply	other threads:[~2013-04-19 12:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-19  9:52 [Qemu-devel] [PATCH] monitor: introduce query-config-schema Amos Kong
2013-04-19 12:02 ` Osier Yang
2013-04-19 12:22   ` Eric Blake
2013-04-19 13:44   ` Osier Yang
2013-04-19 12:39 ` Eric Blake [this message]
2013-04-19 13:50   ` Osier Yang
2013-04-19 15:21 ` Paolo Bonzini
2013-04-22 11:48   ` Amos Kong
2013-04-22 12:07     ` Paolo Bonzini
2013-04-22 15:00       ` Eric Blake
2013-04-22 15:16         ` Paolo Bonzini
2013-04-23  2:40           ` Amos Kong
2013-04-23 13:20         ` Luiz Capitulino
2013-04-23 15:32           ` Eric Blake
2013-04-23 16:55             ` 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=51713B08.1050504@redhat.com \
    --to=eblake@redhat.com \
    --cc=akong@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=jyang@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /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).