[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] help parsing qemu options
From: |
Gabriel L. Somlo |
Subject: |
Re: [Qemu-devel] help parsing qemu options |
Date: |
Tue, 10 Mar 2015 13:35:05 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Tue, Mar 10, 2015 at 09:40:09AM +0100, Markus Armbruster wrote:
> "Gabriel L. Somlo" <address@hidden> 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" ?
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,
--Gabriel
- [Qemu-devel] help parsing qemu options, Gabriel L. Somlo, 2015/03/09
- Re: [Qemu-devel] help parsing qemu options, Markus Armbruster, 2015/03/10
- Re: [Qemu-devel] help parsing qemu options,
Gabriel L. Somlo <=
- Re: [Qemu-devel] help parsing qemu options, Markus Armbruster, 2015/03/11
- Re: [Qemu-devel] help parsing qemu options, Kevin Wolf, 2015/03/11
- Re: [Qemu-devel] help parsing qemu options, Gabriel L. Somlo, 2015/03/11
- Re: [Qemu-devel] help parsing qemu options, Gabriel L. Somlo, 2015/03/11
- Re: [Qemu-devel] help parsing qemu options, Kevin Wolf, 2015/03/11