qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Osier Yang <jyang@redhat.com>
To: Amos Kong <akong@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] monitor: introduce query-config-schema command
Date: Thu, 25 Apr 2013 12:27:16 +0800	[thread overview]
Message-ID: <5178B0A4.3090409@redhat.com> (raw)
In-Reply-To: <20130425035258.GE3230@t430s.nay.redhat.com>

On 25/04/13 11:52, Amos Kong wrote:
> On Wed, Apr 24, 2013 at 01:39:08PM -0600, Eric Blake wrote:
>> On 04/24/2013 12:20 PM, Luiz Capitulino wrote:
>>> On Thu, 25 Apr 2013 01:33:24 +0800
>>> Amos Kong <akong@redhat.com> wrote:
>>>
>>>> Libvirt has no way to probe if an option or property is supported,
>>>> This patch introdues a new qmp command to query configuration schema
>>>> information. hmp command isn't added because it's not needed.
>>>>
>>>> V2: fix jaso schema and comments (Eric)
> ...
>
>>>> +#
>>>> +# @flag: If no value is given, the flag is set to 1. Otherwise the value must
>>>> +#        be "on" (set to 1) or "off" (set to 0)
>>> Let's call this 'boolean', because it's what it is. Also, I suggest
>>> 'Accepts "on" or "off"' as the help text.
>> I'm fine with calling the enum value 'boolean' even where the C code
>> called it 'flag'.  As long as we have a documented name that describes
>> the semantics of what the parameter will take, libvirt should be able to
>> cope.
>>
>> One other concern - you document that if a flag parameter is omitted,
>> then it defaults to 1.  Is that really true?
>
> I'm wrong. If it's omitted in cmdline, we will give it a default value.
>
> example:
>     enable_mlock = qemu_opt_get_bool(opts, "mlock", true);
>
> another example:
>     -boot strict=on
>
>     bool boot_strict; (false by default)
>
>     strict boot is disabled by default, type of strict parameter is 'QEMU_OPT_STRING'
>     the logical default parameter is "off".

I didn't look through all the threads, not sure if it's already 
clarified, but
is the "flags" indicates whether the option is enabled or disabled by 
default?

If so, is it possible to have another "name" instead of "flag"? Or please
add documentation to tell more about the meaning.

>
> This kind of default info is only added in help descriptions right
> now, we can add a new item 'default_value' to option.h:QemuOptDesc &
> qapi-schema.json:CommandLineParameterInfo in future?

Sounds good to add it in the struct instead and dump as a JSON parameter.

>
> I guess the default value is useful for libvirt.

Yeah, sure, it's nice if libvirt could known if the device is enabled or 
disabled
by default.

Osier

  reply	other threads:[~2013-04-25  4:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-24 12:47 [Qemu-devel] [RESEND PATCH 1/2] qapi: introduce strList and visit_type_strList() Amos Kong
2013-04-24 12:47 ` [Qemu-devel] [PATCH 2/2] monitor: introduce query-config-schema command Amos Kong
2013-04-24 14:38   ` Eric Blake
2013-04-24 16:45     ` Anthony Liguori
2013-04-24 17:33   ` [Qemu-devel] [PATCH] " Amos Kong
2013-04-24 17:36     ` [Qemu-devel] [PATCH v2] " Amos Kong
2013-04-24 18:20     ` [Qemu-devel] [PATCH] " Luiz Capitulino
2013-04-24 19:39       ` Eric Blake
2013-04-24 23:55         ` Eric Blake
2013-04-25  3:52         ` Amos Kong
2013-04-25  4:27           ` Osier Yang [this message]
2013-04-25  5:09             ` Amos Kong
2013-04-25 12:36           ` Luiz Capitulino
2013-04-25 13:30             ` Eric Blake
2013-04-25  1:14       ` Amos Kong
2013-04-25  1:35         ` Luiz Capitulino
2013-04-25  1:44           ` Eric Blake
2013-04-25  2:03             ` Amos Kong
2013-04-25  2:14             ` Luiz Capitulino
2013-04-25  1:43         ` Eric Blake
2013-04-25  3:38         ` Osier Yang
2013-04-24 14:01 ` [Qemu-devel] [RESEND PATCH 1/2] qapi: introduce strList and visit_type_strList() Eric Blake
2013-04-24 15:59   ` Amos Kong
2013-04-24 14:39 ` Eric Blake

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=5178B0A4.3090409@redhat.com \
    --to=jyang@redhat.com \
    --cc=akong@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=lcapitulino@redhat.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).