From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXuTm-0001lk-ME for qemu-devel@nongnu.org; Fri, 25 May 2012 09:22:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXuTh-0002li-JC for qemu-devel@nongnu.org; Fri, 25 May 2012 09:22:54 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:44867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXuTh-0002la-Em for qemu-devel@nongnu.org; Fri, 25 May 2012 09:22:49 -0400 Received: from /spool/local by e1.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 May 2012 09:22:43 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 79D6E38C8054 for ; Fri, 25 May 2012 09:17:52 -0400 (EDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4PDHqE4102510 for ; Fri, 25 May 2012 09:17:53 -0400 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4PDGnYd022099 for ; Fri, 25 May 2012 07:16:49 -0600 Message-ID: <4FBF8633.3060803@us.ibm.com> Date: Fri, 25 May 2012 08:16:35 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1337916721-14308-1-git-send-email-akong@redhat.com> <1337916721-14308-3-git-send-email-akong@redhat.com> <4FBF01AE.5000007@redhat.com> <4FBF24B1.8080803@redhat.com> <20120525073454.GC11895@redhat.com> <20120525100611.34a32b6a@doriath.home> In-Reply-To: <20120525100611.34a32b6a@doriath.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] qapi: convert sendkey List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Eric Blake , Amos Kong , qemu-devel@nongnu.org On 05/25/2012 08:06 AM, Luiz Capitulino wrote: > On Fri, 25 May 2012 08:34:54 +0100 > "Daniel P. Berrange" wrote: > >> On Fri, May 25, 2012 at 02:20:33PM +0800, Amos Kong wrote: >>> On 25/05/12 11:51, Eric Blake wrote: >>>> On 05/24/2012 09:32 PM, Amos Kong wrote: >>>>> Convert 'sendkey' to use. do_sendkey() depends on some variables >>>>> in monitor.c, so reserve qmp_sendkey() to monitor.c >>>>> Rename 'string' to 'keys', rename 'hold_time' to 'hold-time' >>>>> >>>>> Signed-off-by: Amos Kong >>>> >>>>> +## >>>>> +# @sendkey: >>>>> +# >>>>> +# Send keys to VM. >>>>> +# >>>>> +# @keys: key sequence >>>>> +# @hold-time: time to delay key up events >>>>> +# >>>>> +# Returns: Nothing on success >>>>> +# If key is unknown or redundant, QERR_INVALID_PARAMETER >>>>> +# If key is invalid, QERR_INVALID_PARAMETER_VALUE >>>>> +# >>>>> +# Notes: Send @var{keys} to the emulator. @var{keys} could be the name of the >>>>> +# key or the raw value in either decimal or hexadecimal format. Use >>>>> +# @code{-} to press several keys simultaneously. >>>>> +# >>>>> +# Since: 0.14.0 >>>>> +## >>>>> +{ 'command': 'sendkey', 'data': {'keys': 'str', '*hold-time': 'int'} } >>>> >>>> Rather than making 'keys' a free-form string where qemu then has to >>>> parse '-' to separate keys, should we instead make it a JSON array? For >>>> example, >>> >>> >>> Anthony, Luiz, Daniel, what's your opinion? >> >> Using a JSON array for the key names does seem like the most >> natural way to model this. A good rule of thumb is that the >> implementation of a command should not need to further >> parse the individual parameter values. Using a magic string >> encoding instead of the JSON array requires such extra special >> case parsing. > > That's true, and I agree this is better. > > Just would like to point out that we can't go too far on improving > HMP-inherited commands, as our goal here is to convert most (or every single) > HMP commands to QMP. If we go far on improving commands, we'll get stuck as we > did some time ago. I agree. But obviously, changing the parameter syntax is straight forward enough. I think we rat hole when we change the command semantics though. > > Btw, I remember someone saying that when libvirt wants to use a HMP command it > first checks if the command exists in QMP before using passthrough. In that case, > how will libvirt behave if we change the arguments? I don't think libvirt can possibly be assuming that a QMP command exists that it's never seen before... So hopefully this isn't a blind check. If it is, it's a libvirt bug. Regards, Anthony Liguori >