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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Mon, 28 Jun 2010 16:40:58 +0200
Jan Kiszka <jan.kiszka@siemens.com> wrote:

> Luiz Capitulino wrote:
> > On Wed, 23 Jun 2010 12:28:27 +0200
> > Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > 
> >> Markus Armbruster wrote:
> >>> Jan Kiszka <jan.kiszka@web.de> writes:
> >>>
> >>>> From: Jan Kiszka <jan.kiszka@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.kiszka@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).

I'm ok with it if it's unambiguous.

> > 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.

Done for them all, except 16/23 which mentions device_show in the changelog.

I should send a pull request until this Wednesday.