On 11/11/2010 09:55 AM, Daniel P. Berrange wrote:
On Thu, Nov 11, 2010 at 04:47:41PM +0100, Markus Armbruster wrote:
Luiz Capitulino<lcapitul...@redhat.com> writes:
On Wed, 10 Nov 2010 14:20:12 +0100
Markus Armbruster<arm...@redhat.com> wrote:
Luiz Capitulino<lcapitul...@redhat.com> writes:
[...]
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 793cf1c..b344096 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -761,6 +761,51 @@ Example:
Note: This command must be issued before issuing any other command.
+EQMP
+
+ {
+ .name = "hmp_passthrough",
+ .args_type = "command-line:s,cpu-index:i?",
+ .params = "",
+ .help = "",
+ .user_print = monitor_user_noop,
+ .mhandler.cmd_new = do_hmp_passthrough,
+ },
+
+SQMP
+hmp_passthrough
+---------------
+
+Execute a Human Monitor command.
+
+Arguments:
+
+- command-line: the command name and its arguments, just like the
+ Human Monitor's shell (json-string)
+- cpu-index: select the CPU number to be used by commands which access CPU
+ data, like 'info registers'. The Monitor selects CPU 0 if this
+ argument is not provided (json-int, optional)
+
+Example:
+
+-> { "execute": "hmp_passthrough", "arguments": { "command-line": "info kvm"
} }
+<- { "return": "kvm support: enabled\r\n" }
+
+Notes:
+
+(1) The Human Monitor is NOT an stable interface, this means that command
+ names, arguments and responses can change or be removed at ANY time.
+ Applications that rely on long term stability guarantees should NOT
+ use this command
+
+(2) Limitations:
+
+ o This command is stateless, this means that commands that depend
+ on state information (such as getfd) might not work
+
+ o Commands that prompt the user for data (eg. 'cont' when the block
+ device is encrypted) don't currently work
+
3. Query Commands
=================
In the real human monitor, cpu-index is state (Monitor member mon_cpu).
For pass through, you shift that state into the client (argument
cpu-index). Is there any other state that could need shifting? You
mention getfd.
Surprisingly or not, this is a very important question for QMP itself.
Anthony has said that we should make it stateless, and I do think this
is good because it seems to simplify things considerably.
However, I haven't thought about how to make things like getfd stateless.
Hmm, that sounds like we should investigate the getfd problem sooner
rather than later.
The SCM_RIGHTS code allows you to send/receive multiple file handles in a
single sendmsg/recvmsg call. So why don't we just allow sending of the
file handles with the monitor command that actually needs them, instead of
ahead of time using send_fd. This simplifies life for the client because
they also don't have to worry about cleanup using close_fd if the command
using the FD fails.
How do we identify file descriptors and then map them to a command?
Regards,
Anthony Liguori
Regards,
Daniel
