Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists
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?
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.
Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists
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
Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists
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.
Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists
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.
[...]
Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists
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.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v4 11/23] monitor: Add completion support for option lists
Jan Kiszka jan.kis...@siemens.com writes:
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.
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.
