Hi,
Assuming I'm trying to add a new command line option to qemu in vl.c:
...
static QemuOptsList qemu_foo_opts = {
.name = "foo",
.implied_opt_name = "name",
.head = QTAILQ_HEAD_INITIALIZER(qemu_foo_opts.head),
.desc = {
{
.name = "name",
.type = QEMU_OPT_STRING,
}, {
.name = "file",
.type = QEMU_OPT_STRING,
},
{ /* end of list */ }
},
};
...
main() {
...
qemu_add_opts(&qemu_foo_opts);
...
/* second pass of option parsing */
...
for(;;) {
...
switch(popt->index) {
...
case QEMU_OPTION_foo:
opts = qemu_opts_parse(qemu_find_opts("foo"), optarg, 0);
if (!foo_option_add(qemu_opt_get(opts, "name"),
qemu_opt_get(opts, "file"))) {
fprintf(stderr, "invalid foo entry config %s\n", optarg);
exit(1);
}
break;
...
}
Somewhere else in the source I have
bool foo_option_add(const char *name, const char *file) {
if (/* everything OK */) {
return true;
}
return false;
}
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).
Thanks much,
--Gabriel
