From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53586 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PGaUc-0001L7-Q9 for qemu-devel@nongnu.org; Thu, 11 Nov 2010 11:59:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PGaUX-0006Cy-UQ for qemu-devel@nongnu.org; Thu, 11 Nov 2010 11:59:22 -0500 Received: from mail-qy0-f180.google.com ([209.85.216.180]:35455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PGaUX-0006Ck-NJ for qemu-devel@nongnu.org; Thu, 11 Nov 2010 11:59:17 -0500 Received: by qyk36 with SMTP id 36so1643472qyk.4 for ; Thu, 11 Nov 2010 08:59:17 -0800 (PST) Message-ID: <4CDC20E0.2040805@codemonkey.ws> Date: Thu, 11 Nov 2010 10:59:12 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] QMP: Introduce Human Monitor passthrough command References: <1288362514-31407-1-git-send-email-lcapitulino@redhat.com> <1288362514-31407-3-git-send-email-lcapitulino@redhat.com> <20101110113637.05d5a202@doriath> <20101111145558.32db2b30@doriath> In-Reply-To: <20101111145558.32db2b30@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, Markus Armbruster , qemu-devel@nongnu.org On 11/11/2010 10:55 AM, Luiz Capitulino wrote: > On Thu, 11 Nov 2010 16:47:41 +0100 > Markus Armbruster wrote: > > >> Luiz Capitulino writes: >> >> >>> On Wed, 10 Nov 2010 14:20:12 +0100 >>> Markus Armbruster wrote: >>> >>> >>>> Luiz Capitulino 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. >> > Absolutely, but this shouldn't prevent this series of being merged, right? > BTW, don't we have all of the fd= commands covered in QMP already? Regards, Anthony Liguori