Re: [Qemu-devel] help parsing qemu options

[Kevin Wolf <kwolf@redhat.com>]

Am 11.03.2015 um 08:52 hat Markus Armbruster geschrieben:
> "Gabriel L. Somlo" <gsomlo@gmail.com> writes:
> 
> > On Tue, Mar 10, 2015 at 09:40:09AM +0100, Markus Armbruster wrote:
> >> "Gabriel L. Somlo" <gsomlo@gmail.com> writes:
> >> > Assuming the above is correct (and that the appropriate glue is added
> >> > to qemu-options.hx to tie "-foo name=abc,file=xyz" to QEMU_OPTION_foo),
> >> > I'm wondering about preventing "name" and "file" from being turned
> >> > into Booleans should their arguments be omitted on the command line.
> >> >
> >> > To clarify:
> >> >
> >> > -foo abcxyz   results in a parse error generated by qemu_opts_parse()
> >> >               which is as it should be
> >> >
> >> > -foo file=abc,name=xyz   results in a call to foo_option_add("xyz", "abc")
> >> >                          which is the desired behavior
> >> >
> >> > -foo file=,name=   results in a call to foo_option_add("", "")
> >> >                    which is also OK, as I can sanity-check my
> >> >                    arguments from within foo_option_add()
> >> >
> >> > However,
> >> >
> >> > -foo file,name    results in a call to foo_option_add("on", "on")
> >> >                   i.e., in the absence of string values, both
> >> >                   "file" and "name" are converted into Booleans
> >> >                   and given the string value "on" by qemu_opts_parse()
> >> >                   which is NOT what I want, and I'm wondering if
> >> >                   that behavior can somehow be turned off for
> >> >                   any given QemuOptsList ?
> >> >
> >> > I guess I could be looking for a file named "on" in the current
> >> > directory, and attempt to use the value "on" to insert the object
> >> > from the given file (and fail if no file named "on" could be found,
> >> > but this is not as clean as I would like it to be, and I'm wondering
> >> > if there's a better way).
> >> 
> >> Reproduced:
> >> 
> >>     $ upstream-qemu -nodefaults -S -display vnc=:0 -monitor stdio
> >> -name process=foo,guest
> >>     QEMU 2.2.50 monitor - type 'help' for more information
> >>     (qemu) info name
> >>     on
> >> 
> >> QemuOpts is baroque.
> >> 
> >> No, you can't switch it off.  I'm afraid adding such a switch is not a
> >> good idea, because it would make QemuOpts even more baroque.
> >> 
> >> Perhaps we can limit the convenience syntax "omitted value means =on" to
> >> boolean options.  Could be hairy, because .desc can be empty, which
> >> defers part of the checking until later.
> >
> > Maybe adding a .default field to .desc, so if the parameter is defined
> > but no value is assigned, the .default value (which could be NULL) is
> > used instead of always defaulting to "on" ?
> 
> Introduces a second way to do defaults.  The existing way is to provide
> them separately for each use, like this:
> 
>    int port = qdict_get_try_int(qdict, "port", -1);
> 
> or this:
> 
>     const char *device = qdict_get_try_str(qdict, "device");
>     if (!device)
>         device = "tcp::" DEFAULT_GDBSTUB_PORT;
> 
> Adding another way begs the question what to do when *both* ways provide
> a default, and they differ.
> 
> Getting the semantics consistent could be hairy, because .desc can be
> empty, which defers part of the checking until later.
> 
> Prior mention of the idea:
> https://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg03813.html
> which elaborates on
> https://lists.nongnu.org/archive/html/qemu-devel/2013-01/msg04598.html

def_value_str exists in the current codebase, and it seems to take
precedence when a different default is specified by the caller.

Kevin