"Gabriel L. Somlo" <gso...@gmail.com> writes:
> On Tue, Mar 10, 2015 at 09:40:09AM +0100, Markus Armbruster wrote:
>> "Gabriel L. Somlo" <gso...@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
> No idea if that'd be worth it though, I was just wondering if there's
> already a mechanism controlling whether fallback-to-bool is a (per
> QemuOptsList struct) tunable option, which I now know it is not :)
>
> Thanks much,
You're welcome :)
