Jan Kiszka <jan.kiszka@siemens.com> writes:
> 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.
Sensible.
Speaking of args_type. We've accumulated too many ways to represent
dynamic data types, and too many ways to describe data types.
The most powerful dynamic data type is QObject. It comes with a useful
plain-text representation (JSON). We lack a data type for describing
QObjects. We use args_type to describe special QObjects, namely monitor
command arguments. We've clearly stretched that to the limit and then
some. We could use a general solution. JSON Schema as its plain-text
representation could be nice.
Then we have QemuOpts. It's more limited (flat list instead of trees),
but it comes with a real data type to describe it (QemuOptsList).
There's also QEMUOptionParameter. Serves a similar purpose. I don't
know why we have both.
Over in qdev-land, we find Property, which can be viewed a data type to
describe (parts of) a struct.
Some unification would be nice.

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