On Mon, 28 Jun 2010 16:40:58 +0200 Jan Kiszka <jan.kis...@siemens.com> wrote:
> 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). 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.