Il 28/01/2014 15:28, Markus Armbruster ha scritto:
I'd rather not promise "all options will take an argument, or desugar
into some option that takes an argument, forever and ever". But I don't
see the need for such a promise. If we decide we want such options, we
just have to do the necessary w
Paolo Bonzini writes:
> Il 28/01/2014 14:16, Markus Armbruster ha scritto:
That would mean we can't ever add an option that doesn't take an
argument again.
>>>
>>> We can add it under an existing QemuOpts group or invent a new one
>>> (like we did for -rt or -msg).
>>
>> Do you mean -rt
Il 28/01/2014 14:16, Markus Armbruster ha scritto:
That would mean we can't ever add an option that doesn't take an
argument again.
We can add it under an existing QemuOpts group or invent a new one
(like we did for -rt or -msg).
Do you mean -rtc?
I meant -rt, but -rtc applies just as well.
[Adding Luiz...]
Paolo Bonzini writes:
> Il 28/01/2014 12:55, Markus Armbruster ha scritto:
>> Paolo Bonzini writes:
>>
>>> Il 28/01/2014 10:36, Markus Armbruster ha scritto:
I think the data you can usefully collect with this approach is
approximately the data getopt_long()[*] gets:
Il 28/01/2014 12:55, Markus Armbruster ha scritto:
Paolo Bonzini writes:
Il 28/01/2014 10:36, Markus Armbruster ha scritto:
I think the data you can usefully collect with this approach is
approximately the data getopt_long()[*] gets: list of named command line
options, and whether they take a
Paolo Bonzini writes:
> Il 28/01/2014 10:36, Markus Armbruster ha scritto:
>> I think the data you can usefully collect with this approach is
>> approximately the data getopt_long()[*] gets: list of named command line
>> options, and whether they take an argument.
>>
>> You can use this data to f
Il 28/01/2014 10:36, Markus Armbruster ha scritto:
I think the data you can usefully collect with this approach is
approximately the data getopt_long()[*] gets: list of named command line
options, and whether they take an argument.
You can use this data to fill in options not covered by QemuOpts
Amos Kong writes:
> Hi QEMU/Libvirt list,
>
> When I worked on query-command-line-options, I first used some marcos [1] to
> generate two config & option tables. This will cover all the options,
> but it returns a string, it's difficult for libvirt to parse and use
> it.
>
> Finally I got a sugge
On 12/22/2013 07:19 PM, Amos Kong wrote:
> Problem:
> * QemuOpts was designed just for options with parameter, some new option
> without parameters is lost in query output (eg: -enable-fips)
> * block drive uses three QemuOpts, it's legacy issue.
> * QemuOpts of some options aren't updated, it m
