From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXuK5-00048C-5y for qemu-devel@nongnu.org; Fri, 25 May 2012 09:12:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXuK2-0000MW-Rd for qemu-devel@nongnu.org; Fri, 25 May 2012 09:12:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXuK2-0000ML-JL for qemu-devel@nongnu.org; Fri, 25 May 2012 09:12:50 -0400 Date: Fri, 25 May 2012 14:12:39 +0100 From: "Daniel P. Berrange" Message-ID: <20120525131239.GJ11895@redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120525100611.34a32b6a@doriath.home> Subject: Re: [Qemu-devel] [PATCH 3/3] qapi: convert sendkey Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, Amos Kong , Eric Blake , qemu-devel@nongnu.org On Fri, May 25, 2012 at 10:06:11AM -0300, 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. > > 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? We're not talking about changing the args of the existing HMP command, and libvirt has no code for a QMP version of sendkey, so there's no compatibility issue. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|