qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for op


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists
Date: Wed, 23 Jun 2010 12:28:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Markus Armbruster wrote:
> Jan Kiszka <address@hidden> writes:
> 
>> From: Jan Kiszka <address@hidden>
>>
>> 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 <address@hidden>
>> ---
>>  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.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]