From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NaZ8N-00076g-Ng for qemu-devel@nongnu.org; Thu, 28 Jan 2010 13:30:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NaZ8I-000763-5V for qemu-devel@nongnu.org; Thu, 28 Jan 2010 13:30:26 -0500 Received: from [199.232.76.173] (port=33209 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NaZ8H-000760-VE for qemu-devel@nongnu.org; Thu, 28 Jan 2010 13:30:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17116) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NaZ8H-0002eK-D0 for qemu-devel@nongnu.org; Thu, 28 Jan 2010 13:30:21 -0500 Message-ID: <4B61D782.1010800@redhat.com> Date: Thu, 28 Jan 2010 19:29:22 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] New API for asynchronous monitor commands (V2) References: <1264443524.2890.3.camel@aglitke> In-Reply-To: <1264443524.2890.3.camel@aglitke> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Litke Cc: Luiz Capitulino , qemu-devel@nongnu.org, Avi Kivity Am 25.01.2010 19:18, schrieb Adam Litke: > Changes since V1: > - Miscellaneous code cleanups (Thanks Luiz) > > 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 This commit introduces a segfault on info pci for me. The following patch seems to make it work again. Is it correct or is rather info pci doing something wrong? diff --git a/monitor.c b/monitor.c index fbae5ce..22690c4 100644 --- a/monitor.c +++ b/monitor.c @@ -3700,7 +3700,12 @@ static void monitor_print_error(Monitor *mon) static int is_async_return(const QObject *data) { - return data && qdict_haskey(qobject_to_qdict(data), "__mon_async"); + const QDict *dict = NULL; + + if (data != NULL) { + dict = qobject_to_qdict(data); + } + return dict && qdict_haskey(dict, "__mon_async"); } static void monitor_call_handler(Monitor *mon, const mon_cmd_t *cmd, Kevin