Luiz Capitulino wrote:
> On Wed, 23 Jun 2010 12:28:27 +0200
> Jan Kiszka <jan.kis...@siemens.com> wrote:
>
>> Markus Armbruster wrote:
>>> Jan Kiszka <jan.kis...@web.de> writes:
>>>
>>>> From: Jan Kiszka <jan.kis...@siemens.com>
>>>>
>>>> This enables command line completion inside option strings. A list of
>>>> expected key names and their completion type can be appended to the 'O'
>>>> inside parentheses ('O(key:type,...)'). The first use case is block
>>>> device completion for the 'drive' option of 'device_add'.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
>>>> ---
>>>> monitor.c | 68
>>>> ++++++++++++++++++++++++++++++++++++++++++++++---------
>>>> qemu-monitor.hx | 2 +-
>>>> 2 files changed, 58 insertions(+), 12 deletions(-)
>>>>
>>>> diff --git a/monitor.c b/monitor.c
>>>> index c1006b4..3e0d862 100644
>>>> --- a/monitor.c
>>>> +++ b/monitor.c
>>>> @@ -68,6 +68,9 @@
>>>> * 'O' option string of the form NAME=VALUE,...
>>>> * parsed according to QemuOptsList given by its name
>>>> * Example: 'device:O' uses qemu_device_opts.
>>>> + * Command completion for specific keys can be requested via
>>>> + * appending '(NAME:TYPE,...)' with 'F', 'B' as type.
>>>> + * Example: 'device:O(bus:Q)' to expand 'bus=...' as qtree
>>>> path.
>>>> * Restriction: only lists with empty desc are supported
>>>> * TODO lift the restriction
>>>> * 'i' 32 bit integer
>>> Ugh.
>>>
>>> Replacement of args_type by a proper data structure is long overdue. We
>>> keep piling features into that poor, hapless string.
>>>
>>> Information on how to complete QemuOptsList options arguably belongs
>>> into the option description, i.e. QemuOptDesc.
>> For sure, that would be better. I just wonder how much of it should be
>> stuffed into this series. I guess I will drop this part for now, just
>> focusing on what device_show makes direct use of. Same for separate args
>> for HMP and QMP.
>
> IIRC, the separate args idea use case was to allow commands like device_del
> to have an ID argument and a path argument, right? If so, I think it doesn't
> matter anymore as we have agreed on having a device argument which would
> accept both, even under QMP, right Markus?
To my understanding: As a leading element in qdev path, at least to
address a device, maybe also to abbreviate only the beginning of a full
path (that's currently to major remaining open issue).
>
> By the way, if you send patches 09/23, 10/23, 15/23, (maybe) 16/23, 21/23
> and 22/23 in a different series, I could try pushing them in my next
> pull request.
Do they need rebasing? If not, feel free to pick them up as you like. My
series requires a v5 round anyway once discussion on path construction
finally came to an end.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
