qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 2/4] monitor: New argument type 'b'


From: Markus Armbruster
Subject: [Qemu-devel] Re: [PATCH 2/4] monitor: New argument type 'b'
Date: Thu, 25 Mar 2010 18:28:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Luiz Capitulino <address@hidden> writes:

> On Tue, 23 Mar 2010 11:27:56 +0100
> Markus Armbruster <address@hidden> wrote:
>
>> This is a boolean value.  Human monitor accepts "on" or "off".
>> Consistent with option parsing (see parse_option_bool()).
>> 
>> Signed-off-by: Markus Armbruster <address@hidden>
>> ---
>>  monitor.c |   31 +++++++++++++++++++++++++++++++
>>  1 files changed, 31 insertions(+), 0 deletions(-)
>> 
>> diff --git a/monitor.c b/monitor.c
>> index 3ce9a4e..47b68a2 100644
>> --- a/monitor.c
>> +++ b/monitor.c
>> @@ -85,6 +85,8 @@
>>   *
>>   * '?'          optional type (for all types, except '/')
>>   * '.'          other form of optional type (for 'i' and 'l')
>> + * 'b'          boolean
>> + *              user mode accepts "on" or "off"
>>   * '-'          optional parameter (eg. '-f')
>>   *
>>   */
>> @@ -3841,6 +3843,29 @@ static const mon_cmd_t *monitor_parse_command(Monitor 
>> *mon,
>>                  qdict_put(qdict, key, qfloat_from_double(val));
>>              }
>>              break;
>> +        case 'b':
>> +            {
>> +                const char *beg;
>> +                int val;
>> +
>> +                while (qemu_isspace(*p)) {
>> +                    p++;
>> +                }
>> +                beg = p;
>> +                while (qemu_isgraph(*p)) {
>> +                    p++;
>> +                }
>> +                if (!strncmp(beg, "on", p - beg)) {
>> +                    val = 1;
>> +                } else if (!strncmp(beg, "off", p - beg)) {
>> +                    val = 0;
>> +                } else {
>> +                    monitor_printf(mon, "Expected 'on' or 'off'\n");
>> +                    goto fail;
>> +                }
>
>  This will make 'on' be the default when no on/off is specified, is that
> your intention? I'm wondering if this can cause problems when you add
> optional support for it and mixes it with other arguments.

No.  Intended behavior: the argument must be either "on" or "off".  With
"on", (KEY, true) is put into the dictionary, for "off" it's (KEY,
false).

We get a third case for optional argument if we support that: KEY not in
dictionary.  The handler decides how to interpret that.

[...]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]