From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYSkz-0006uy-0S for qemu-devel@nongnu.org; Fri, 22 Jan 2010 18:17:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYSku-0006na-BB for qemu-devel@nongnu.org; Fri, 22 Jan 2010 18:17:36 -0500 Received: from [199.232.76.173] (port=51268 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYSku-0006nO-4f for qemu-devel@nongnu.org; Fri, 22 Jan 2010 18:17:32 -0500 Received: from mail-iw0-f197.google.com ([209.85.223.197]:62946) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYSkt-00033g-Ak for qemu-devel@nongnu.org; Fri, 22 Jan 2010 18:17:31 -0500 Received: by iwn35 with SMTP id 35so655695iwn.4 for ; Fri, 22 Jan 2010 15:17:30 -0800 (PST) Message-ID: <4B5A3207.5030105@codemonkey.ws> Date: Fri, 22 Jan 2010 17:17:27 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1264187031.2861.13.camel@aglitke> In-Reply-To: <1264187031.2861.13.camel@aglitke> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC] New API for asynchronous monitor commands List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Litke Cc: Markus Armbruster , Avi Kivity , qemu-devel@nongnu.org, Luiz Capitulino On 01/22/2010 01:03 PM, Adam Litke wrote: > Qemu has a number of commands that can operate asynchronously (savevm, migrate, > etc) and it will be getting more. For these commands, the user monitor needs > to be suspended, but QMP monitors could continue to to accept other commands. > This patch introduces a new command API that isolates the details of handling > different monitor types from the actual command execution. > > A monitor command can use this API by implementing the mhandler.cmd_async > handler (or info_async if appropriate). This function is responsible for > submitting the command and does not return any data although it may raise > errors. When the command completes, the QMPCompletion callback should be > invoked with its opaque data and the command result. > > The process for submitting and completing an asynchronous command is different > for QMP and user monitors. A user monitor must be suspended at submit time and > resumed at completion time. The user_print() function must be passed to the > QMPCompletion callback so the result can be displayed properly. QMP monitors > are simpler. No submit time setup is required. When the command completes, > monitor_protocol_emitter() writes the result in JSON format. > > This API can also be used to implement synchronous commands. In this case, the > cmd_async handler should immediately call the QMPCompletion callback. It is my > hope that this new interface will work for all commands, leading to a > drastically simplified monitor.c once all commands are ported. > > Thanks to Anthony for helping me out with the initial design. > > Signed-off-by: Adam Litke > To: Anthony Liguori > cc: Luiz Capitulino > Cc: qemu-devel@nongnu.org > I like this a lot and I'd like to see us remove cmd_new in place of cmd_async. The conversion is pretty easy since we just have to add a cb(ret_data) to the end of synchronous functions. Luiz/Markus/Avi, what do ya'll think? Regards, Anthony Liguori