Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
Am 29.05.2013 um 19:51 hat Luiz Capitulino geschrieben:
On Wed, 29 May 2013 10:13:42 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
On 05/28/2013 09:27 AM, Kevin Wolf wrote:
The QMP version is flagged with a __org.qemu.debug- prefix in order to
reinforce the statement that qemu-io is for testing and debugging only,
with no API guarantees.
Correct use of naming conventions.
Hmm, I wonder if the recent addition of an 'abort' action to
'transaction' should be renamed __org.qemu.debug-abort, to make it
obvious that it is another case of a QMP command useful mainly for
testing, and not real-life use.
Makes sense to me.
But first I'd like to get Luiz's ack for this, because I think I'm the
first one to use an __org.qemu prefix, and I'm the first one trying to
introduce a QMP command without API stability.
I think that should be fine. However, it's not a perfect match for QMP
as you don't expect mngt to use it anytime soon and that the command's
syntax is not QMP friendly:
{ execute: __org.qemu.debug-qemu-io-command, arguments:
{ device: ide0-hd0, command: write -P 0x12 4M 512k } }
What about adding a HMP-only command (the good old way) and use it
through human-monitor-command?
IMO, this matches better your current use-case and the API instability
of the command.
Works for me, but wasn't the plan to make HMP purely a wrapper around
QMP? Then adding HMP-only commands would be counterproductive. So I
assumed that QMP is a must. I didn't even know that the code still
allows you to have HMP-only commands. :-)
So you prefer a respin with the QMP part dropped?
Kevin
Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
On Tue, 4 Jun 2013 12:08:23 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 29.05.2013 um 19:51 hat Luiz Capitulino geschrieben:
On Wed, 29 May 2013 10:13:42 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
On 05/28/2013 09:27 AM, Kevin Wolf wrote:
The QMP version is flagged with a __org.qemu.debug- prefix in order to
reinforce the statement that qemu-io is for testing and debugging
only,
with no API guarantees.
Correct use of naming conventions.
Hmm, I wonder if the recent addition of an 'abort' action to
'transaction' should be renamed __org.qemu.debug-abort, to make it
obvious that it is another case of a QMP command useful mainly for
testing, and not real-life use.
Makes sense to me.
But first I'd like to get Luiz's ack for this, because I think I'm the
first one to use an __org.qemu prefix, and I'm the first one trying to
introduce a QMP command without API stability.
I think that should be fine. However, it's not a perfect match for QMP
as you don't expect mngt to use it anytime soon and that the command's
syntax is not QMP friendly:
{ execute: __org.qemu.debug-qemu-io-command, arguments:
{ device: ide0-hd0, command: write -P 0x12 4M 512k } }
What about adding a HMP-only command (the good old way) and use it
through human-monitor-command?
IMO, this matches better your current use-case and the API instability
of the command.
Works for me, but wasn't the plan to make HMP purely a wrapper around
QMP? Then adding HMP-only commands would be counterproductive. So I
assumed that QMP is a must. I didn't even know that the code still
allows you to have HMP-only commands. :-)
Yes, the long term plan is to have all HMP commands calling QMP
counterparts. But the command you're adding doesn't fit QMP's design
very well.
I suggested adding it as HMP-only for now because it's the simplest
thing to do for this very specific case.
If more test-only non-QMP-friendly commands appear, then we'll need
to think of a more general solution.
Now, something has just occurred to me. Why isn't it a good idea having
this command as a stable API? Wouldn't it be a good idea to allow
out-of-tree test tools like autotest to use it?
So you prefer a respin with the QMP part dropped?
Yes.
Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
On Tue, 4 Jun 2013 14:49:55 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 04.06.2013 um 14:40 hat Luiz Capitulino geschrieben:
On Tue, 4 Jun 2013 12:08:23 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 29.05.2013 um 19:51 hat Luiz Capitulino geschrieben:
On Wed, 29 May 2013 10:13:42 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
On 05/28/2013 09:27 AM, Kevin Wolf wrote:
The QMP version is flagged with a __org.qemu.debug- prefix in
order to
reinforce the statement that qemu-io is for testing and debugging
only,
with no API guarantees.
Correct use of naming conventions.
Hmm, I wonder if the recent addition of an 'abort' action to
'transaction' should be renamed __org.qemu.debug-abort, to make it
obvious that it is another case of a QMP command useful mainly for
testing, and not real-life use.
Makes sense to me.
But first I'd like to get Luiz's ack for this, because I think I'm the
first one to use an __org.qemu prefix, and I'm the first one trying to
introduce a QMP command without API stability.
I think that should be fine. However, it's not a perfect match for QMP
as you don't expect mngt to use it anytime soon and that the command's
syntax is not QMP friendly:
{ execute: __org.qemu.debug-qemu-io-command, arguments:
{ device: ide0-hd0, command: write -P 0x12 4M 512k } }
What about adding a HMP-only command (the good old way) and use it
through human-monitor-command?
IMO, this matches better your current use-case and the API instability
of the command.
Works for me, but wasn't the plan to make HMP purely a wrapper around
QMP? Then adding HMP-only commands would be counterproductive. So I
assumed that QMP is a must. I didn't even know that the code still
allows you to have HMP-only commands. :-)
Yes, the long term plan is to have all HMP commands calling QMP
counterparts. But the command you're adding doesn't fit QMP's design
very well.
It fits the design about as well as human-monitor-command. Both are
passthrough commands, one to HMP, the other one to qemu-io.
Yes, but human-monitor-command is a stop gap command meant to be an
exception. It's usage should decrease over time. I'd expect the opposite
for qemu-io-command.
I suggested adding it as HMP-only for now because it's the simplest
thing to do for this very specific case.
If more test-only non-QMP-friendly commands appear, then we'll need
to think of a more general solution.
What does for now mean, and what will the proper long-term solution
look like?
For now means: until we know what the proper solution should be. I Honestly
don't know what's the best/proper solution here, that's why I suggested
having this in HMP first, so that we don't commit ourselves to anything
prematurely.
Now, something has just occurred to me. Why isn't it a good idea having
this command as a stable API? Wouldn't it be a good idea to allow
out-of-tree test tools like autotest to use it?
Because qemu-io exposes internals of the block layer that we don't want
to make a stable API.
What kind of internals? In the example you posted I see just a generic
enough write command.
Autotest can have test cases using this, but
they'd have to be against a specific qemu version.
So you prefer a respin with the QMP part dropped?
Yes.
Okay, I'll do that.
Kevin
Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
Am 04.06.2013 um 14:40 hat Luiz Capitulino geschrieben:
On Tue, 4 Jun 2013 12:08:23 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 29.05.2013 um 19:51 hat Luiz Capitulino geschrieben:
On Wed, 29 May 2013 10:13:42 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
On 05/28/2013 09:27 AM, Kevin Wolf wrote:
The QMP version is flagged with a __org.qemu.debug- prefix in order
to
reinforce the statement that qemu-io is for testing and debugging
only,
with no API guarantees.
Correct use of naming conventions.
Hmm, I wonder if the recent addition of an 'abort' action to
'transaction' should be renamed __org.qemu.debug-abort, to make it
obvious that it is another case of a QMP command useful mainly for
testing, and not real-life use.
Makes sense to me.
But first I'd like to get Luiz's ack for this, because I think I'm the
first one to use an __org.qemu prefix, and I'm the first one trying to
introduce a QMP command without API stability.
I think that should be fine. However, it's not a perfect match for QMP
as you don't expect mngt to use it anytime soon and that the command's
syntax is not QMP friendly:
{ execute: __org.qemu.debug-qemu-io-command, arguments:
{ device: ide0-hd0, command: write -P 0x12 4M 512k } }
What about adding a HMP-only command (the good old way) and use it
through human-monitor-command?
IMO, this matches better your current use-case and the API instability
of the command.
Works for me, but wasn't the plan to make HMP purely a wrapper around
QMP? Then adding HMP-only commands would be counterproductive. So I
assumed that QMP is a must. I didn't even know that the code still
allows you to have HMP-only commands. :-)
Yes, the long term plan is to have all HMP commands calling QMP
counterparts. But the command you're adding doesn't fit QMP's design
very well.
It fits the design about as well as human-monitor-command. Both are
passthrough commands, one to HMP, the other one to qemu-io.
I suggested adding it as HMP-only for now because it's the simplest
thing to do for this very specific case.
If more test-only non-QMP-friendly commands appear, then we'll need
to think of a more general solution.
What does for now mean, and what will the proper long-term solution
look like?
Now, something has just occurred to me. Why isn't it a good idea having
this command as a stable API? Wouldn't it be a good idea to allow
out-of-tree test tools like autotest to use it?
Because qemu-io exposes internals of the block layer that we don't want
to make a stable API. Autotest can have test cases using this, but
they'd have to be against a specific qemu version.
So you prefer a respin with the QMP part dropped?
Yes.
Okay, I'll do that.
Kevin
Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
On 05/28/2013 09:27 AM, Kevin Wolf wrote:
The QMP version is flagged with a __org.qemu.debug- prefix in order to
reinforce the statement that qemu-io is for testing and debugging only,
with no API guarantees.
Correct use of naming conventions.
Hmm, I wonder if the recent addition of an 'abort' action to
'transaction' should be renamed __org.qemu.debug-abort, to make it
obvious that it is another case of a QMP command useful mainly for
testing, and not real-life use.
Makes sense to me.
But first I'd like to get Luiz's ack for this, because I think I'm the
first one to use an __org.qemu prefix, and I'm the first one trying to
introduce a QMP command without API stability.
The HMP version is simply called 'qemu-io' for convenience.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
+++ b/hmp-commands.hx
@@ -1551,6 +1551,22 @@ Removes the chardev @var{id}.
ETEXI
{
+.name = qemu-io,
+.args_type = device:B,command:s,
+.params = [device] \[command]\,
+.help = run a qemu-io command on a block device,
+.mhandler.cmd = hmp_qemu_io,
+},
+
+STEXI
+@item chardev_remove id
+@findex chardev_remove
+
+Removes the chardev @var{id}.
Is this the right documentation?
Obviously not. I find these files where you declare monitor commands
horribly confusing, and this is the result...
+++ b/qapi-schema.json
@@ -3618,3 +3618,19 @@
'*cpuid-input-ecx': 'int',
'cpuid-register': 'X86CPURegister32',
'features': 'int' } }
+
+##
+# @__org.qemu.debug-qemu-io-command
+#
+# Execute a qemu-io command
+#
+# @device: The block device on which the command should be executed
+#
+# @command: The command to execute
+#
+# Returns: Nothing on success
+#
+# Since: 1.6 (testing and debugging use only, no API stability)
+##
+{ 'command': '__org.qemu.debug-qemu-io-command',
+ 'data': {'device': 'str', 'command': 'str'} }
I would have asked that 'command' be an enum, except that we promise no
API stability so there's no need to lock us into an enum that could be
introspected :) This command looks fine as-is.
Wouldn't even work because the command includes parameters and things.
This is really what you would type on the qemu-io command line. So a
typical example might look like:
{ execute: __org.qemu.debug-qemu-io-command, arguments:
{ device: ide0-hd0, command: write -P 0x12 4M 512k } }
There's nothing structured about it, but for testing and debugging this
should be good enough.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index ffd130e..8682bea 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2932,3 +2932,31 @@ Example:
- { return: {} }
EQMP
+
+{
+.name = __org.qemu.debug-qemu-io-command,
+.args_type = device:s,command:s,
+.mhandler.cmd_new =
qmp_marshal_input___org_qemu_debug_qemu_io_command,
+},
+
+
+SQMP
+__org.qemu.debug-qemu-io-command
+
Do we really need to have SQMP documentation of the command, or is
listing of its handler sufficient? In other words, if this is
debug-only, can we just leave it undocumented instead of listing an
example only to declare the example non-portable?
I don't mind either way. Luiz?
Kevin
Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
On 05/29/2013 02:13 AM, Kevin Wolf wrote:
Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
On 05/28/2013 09:27 AM, Kevin Wolf wrote:
The QMP version is flagged with a __org.qemu.debug- prefix in order to
reinforce the statement that qemu-io is for testing and debugging only,
with no API guarantees.
Correct use of naming conventions.
Hmm, I wonder if the recent addition of an 'abort' action to
'transaction' should be renamed __org.qemu.debug-abort, to make it
obvious that it is another case of a QMP command useful mainly for
testing, and not real-life use.
Makes sense to me.
But first I'd like to get Luiz's ack for this, because I think I'm the
first one to use an __org.qemu prefix, and I'm the first one trying to
introduce a QMP command without API stability.
qom-get/qom-set is somewhat of an unstable API (not that the parameters
of the call will change, but that the underlying qom model is not locked
down, and therefore you cannot blindly rely on a qom command that worked
in one version to continue working in future versions). [Hmm, do we
have a good way to introspect the qom model?]
But yes, this is indeed a different class of unstable interface, and
worth agreeing that we have best practice in mind before committing to it.
+{ 'command': '__org.qemu.debug-qemu-io-command',
+ 'data': {'device': 'str', 'command': 'str'} }
I would have asked that 'command' be an enum, except that we promise no
API stability so there's no need to lock us into an enum that could be
introspected :) This command looks fine as-is.
Wouldn't even work because the command includes parameters and things.
This is really what you would type on the qemu-io command line. So a
typical example might look like:
{ execute: __org.qemu.debug-qemu-io-command, arguments:
{ device: ide0-hd0, command: write -P 0x12 4M 512k } }
There's nothing structured about it, but for testing and debugging this
should be good enough.
I would suggest that you consider using 'command':['str'], so that at
least you have structure that allows you to pass separate arguments (and
thus pass an argument with spaces in the future, should the need arise):
{ execute: __org.qemu.debug-qemu-io-command, arguments:
{ device: ide0-hd0,
command: [ write, -P, 0x12, 4M, 512k ] } }
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
On Wed, 29 May 2013 10:13:42 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 28.05.2013 um 18:07 hat Eric Blake geschrieben:
On 05/28/2013 09:27 AM, Kevin Wolf wrote:
The QMP version is flagged with a __org.qemu.debug- prefix in order to
reinforce the statement that qemu-io is for testing and debugging only,
with no API guarantees.
Correct use of naming conventions.
Hmm, I wonder if the recent addition of an 'abort' action to
'transaction' should be renamed __org.qemu.debug-abort, to make it
obvious that it is another case of a QMP command useful mainly for
testing, and not real-life use.
Makes sense to me.
But first I'd like to get Luiz's ack for this, because I think I'm the
first one to use an __org.qemu prefix, and I'm the first one trying to
introduce a QMP command without API stability.
I think that should be fine. However, it's not a perfect match for QMP
as you don't expect mngt to use it anytime soon and that the command's
syntax is not QMP friendly:
{ execute: __org.qemu.debug-qemu-io-command, arguments:
{ device: ide0-hd0, command: write -P 0x12 4M 512k } }
What about adding a HMP-only command (the good old way) and use it
through human-monitor-command?
IMO, this matches better your current use-case and the API instability
of the command.
[Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
The QMP version is flagged with a __org.qemu.debug- prefix in order to
reinforce the statement that qemu-io is for testing and debugging only,
with no API guarantees.
The HMP version is simply called 'qemu-io' for convenience.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
Makefile | 2 +-
Makefile.objs| 1 +
blockdev.c | 15 +++
hmp-commands.hx | 16
hmp.c| 10 ++
hmp.h| 1 +
qapi-schema.json | 16
qmp-commands.hx | 28
8 files changed, 88 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 581150f..2b85af8 100644
--- a/Makefile
+++ b/Makefile
@@ -186,7 +186,7 @@ qemu-img.o: qemu-img-cmds.h
qemu-img$(EXESUF): qemu-img.o $(block-obj-y) libqemuutil.a libqemustub.a
qemu-nbd$(EXESUF): qemu-nbd.o $(block-obj-y) libqemuutil.a libqemustub.a
-qemu-io$(EXESUF): qemu-io.o qemu-io-cmds.o $(block-obj-y) libqemuutil.a
libqemustub.a
+qemu-io$(EXESUF): qemu-io.o $(block-obj-y) libqemuutil.a libqemustub.a
qemu-bridge-helper$(EXESUF): qemu-bridge-helper.o
diff --git a/Makefile.objs b/Makefile.objs
index 286ce06..5b288ba 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -13,6 +13,7 @@ block-obj-$(CONFIG_POSIX) += aio-posix.o
block-obj-$(CONFIG_WIN32) += aio-win32.o
block-obj-y += block/
block-obj-y += qapi-types.o qapi-visit.o
+block-obj-y += qemu-io-cmds.o
block-obj-y += qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o
block-obj-y += qemu-coroutine-sleep.o
diff --git a/blockdev.c b/blockdev.c
index 789ad9f..9f9f920 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -43,6 +43,7 @@
#include qmp-commands.h
#include trace.h
#include sysemu/arch_init.h
+#include qemu-io.h
static QTAILQ_HEAD(drivelist, DriveInfo) drives =
QTAILQ_HEAD_INITIALIZER(drives);
extern QemuOptsList qemu_common_drive_opts;
@@ -1604,6 +1605,20 @@ BlockJobInfoList *qmp_query_block_jobs(Error **errp)
return dummy.next;
}
+void qmp___org_qemu_debug_qemu_io_command(const char *device, const char *cmd,
+ Error **errp)
+{
+BlockDriverState *bs;
+
+bs = bdrv_find(device);
+if (!bs) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, device);
+return;
+}
+
+qemuio_command(bs, cmd);
+}
+
QemuOptsList qemu_common_drive_opts = {
.name = drive,
.head = QTAILQ_HEAD_INITIALIZER(qemu_common_drive_opts.head),
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 9cea415..9d4c04f 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1551,6 +1551,22 @@ Removes the chardev @var{id}.
ETEXI
{
+.name = qemu-io,
+.args_type = device:B,command:s,
+.params = [device] \[command]\,
+.help = run a qemu-io command on a block device,
+.mhandler.cmd = hmp_qemu_io,
+},
+
+STEXI
+@item chardev_remove id
+@findex chardev_remove
+
+Removes the chardev @var{id}.
+
+ETEXI
+
+{
.name = info,
.args_type = item:s?,
.params = [subcommand],
diff --git a/hmp.c b/hmp.c
index 4fb76ec..9cea8d8 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1425,3 +1425,13 @@ void hmp_chardev_remove(Monitor *mon, const QDict *qdict)
qmp_chardev_remove(qdict_get_str(qdict, id), local_err);
hmp_handle_error(mon, local_err);
}
+
+void hmp_qemu_io(Monitor *mon, const QDict *qdict)
+{
+Error *local_err = NULL;
+const char* device = qdict_get_str(qdict, device);
+const char* command = qdict_get_str(qdict, command);
+
+qmp___org_qemu_debug_qemu_io_command(device, command, local_err);
+hmp_handle_error(mon, local_err);
+}
diff --git a/hmp.h b/hmp.h
index 95fe76e..56d2e92 100644
--- a/hmp.h
+++ b/hmp.h
@@ -85,5 +85,6 @@ void hmp_nbd_server_add(Monitor *mon, const QDict *qdict);
void hmp_nbd_server_stop(Monitor *mon, const QDict *qdict);
void hmp_chardev_add(Monitor *mon, const QDict *qdict);
void hmp_chardev_remove(Monitor *mon, const QDict *qdict);
+void hmp_qemu_io(Monitor *mon, const QDict *qdict);
#endif
diff --git a/qapi-schema.json b/qapi-schema.json
index ef1f657..cc4a083 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3618,3 +3618,19 @@
'*cpuid-input-ecx': 'int',
'cpuid-register': 'X86CPURegister32',
'features': 'int' } }
+
+##
+# @__org.qemu.debug-qemu-io-command
+#
+# Execute a qemu-io command
+#
+# @device: The block device on which the command should be executed
+#
+# @command: The command to execute
+#
+# Returns: Nothing on success
+#
+# Since: 1.6 (testing and debugging use only, no API stability)
+##
+{ 'command': '__org.qemu.debug-qemu-io-command',
+ 'data': {'device': 'str', 'command': 'str'} }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index ffd130e..8682bea 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2932,3 +2932,31 @@ Example:
- { return: {} }
EQMP
+
+{
+.name = __org.qemu.debug-qemu-io-command,
+.args_type =
Re: [Qemu-devel] [PATCH 16/16] Make qemu-io commands available in the monitor
On 05/28/2013 09:27 AM, Kevin Wolf wrote:
The QMP version is flagged with a __org.qemu.debug- prefix in order to
reinforce the statement that qemu-io is for testing and debugging only,
with no API guarantees.
Correct use of naming conventions.
Hmm, I wonder if the recent addition of an 'abort' action to
'transaction' should be renamed __org.qemu.debug-abort, to make it
obvious that it is another case of a QMP command useful mainly for
testing, and not real-life use.
The HMP version is simply called 'qemu-io' for convenience.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
+++ b/hmp-commands.hx
@@ -1551,6 +1551,22 @@ Removes the chardev @var{id}.
ETEXI
{
+.name = qemu-io,
+.args_type = device:B,command:s,
+.params = [device] \[command]\,
+.help = run a qemu-io command on a block device,
+.mhandler.cmd = hmp_qemu_io,
+},
+
+STEXI
+@item chardev_remove id
+@findex chardev_remove
+
+Removes the chardev @var{id}.
Is this the right documentation?
+++ b/qapi-schema.json
@@ -3618,3 +3618,19 @@
'*cpuid-input-ecx': 'int',
'cpuid-register': 'X86CPURegister32',
'features': 'int' } }
+
+##
+# @__org.qemu.debug-qemu-io-command
+#
+# Execute a qemu-io command
+#
+# @device: The block device on which the command should be executed
+#
+# @command: The command to execute
+#
+# Returns: Nothing on success
+#
+# Since: 1.6 (testing and debugging use only, no API stability)
+##
+{ 'command': '__org.qemu.debug-qemu-io-command',
+ 'data': {'device': 'str', 'command': 'str'} }
I would have asked that 'command' be an enum, except that we promise no
API stability so there's no need to lock us into an enum that could be
introspected :) This command looks fine as-is.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index ffd130e..8682bea 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2932,3 +2932,31 @@ Example:
- { return: {} }
EQMP
+
+{
+.name = __org.qemu.debug-qemu-io-command,
+.args_type = device:s,command:s,
+.mhandler.cmd_new =
qmp_marshal_input___org_qemu_debug_qemu_io_command,
+},
+
+
+SQMP
+__org.qemu.debug-qemu-io-command
+
Do we really need to have SQMP documentation of the command, or is
listing of its handler sufficient? In other words, if this is
debug-only, can we just leave it undocumented instead of listing an
example only to declare the example non-portable?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
