From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57507 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4FuL-0008UN-6H for qemu-devel@nongnu.org; Mon, 28 Mar 2011 13:07:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4Fu8-0006Mx-5z for qemu-devel@nongnu.org; Mon, 28 Mar 2011 13:07:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4Fu7-0006MV-Sa for qemu-devel@nongnu.org; Mon, 28 Mar 2011 13:07:00 -0400 Date: Mon, 28 Mar 2011 14:06:51 -0300 From: Luiz Capitulino Message-ID: <20110328140651.13f10e43@doriath> In-Reply-To: <4D90BEDC.6050207@us.ibm.com> References: <1301082479-4058-1-git-send-email-mdroth@linux.vnet.ibm.com> <1301082479-4058-6-git-send-email-mdroth@linux.vnet.ibm.com> <4D8D0788.7070700@us.ibm.com> <20110328134747.5c9fbc8e@doriath> <4D90BEDC.6050207@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][PATCH v1 05/12] qapi: fix handling for null-return async callbacks List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: aliguori@linux.vnet.ibm.com, agl@linux.vnet.ibm.com, Michael Roth , Jes.Sorensen@redhat.com, qemu-devel@nongnu.org On Mon, 28 Mar 2011 12:01:16 -0500 Anthony Liguori wrote: > On 03/28/2011 11:47 AM, Luiz Capitulino wrote: > > On Fri, 25 Mar 2011 16:22:16 -0500 > > Anthony Liguori wrote: > > > >> On 03/25/2011 02:47 PM, Michael Roth wrote: > >>> Async commands like 'guest-ping' have NULL retvals. Handle these by > >>> inserting an empty dictionary in the response's "return" field. > >>> > >>> Signed-off-by: Michael Roth > >>> --- > >>> qmp-core.c | 5 ++++- > >>> 1 files changed, 4 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/qmp-core.c b/qmp-core.c > >>> index e33f7a4..9f3d182 100644 > >>> --- a/qmp-core.c > >>> +++ b/qmp-core.c > >>> @@ -922,9 +922,12 @@ void qmp_async_complete_command(QmpCommandState *cmd, QObject *retval, Error *er > >>> rsp = qdict_new(); > >>> if (err) { > >>> qdict_put_obj(rsp, "error", error_get_qobject(err)); > >>> - } else { > >>> + } else if (retval) { > >>> qobject_incref(retval); > >>> qdict_put_obj(rsp, "return", retval); > >>> + } else { > >>> + /* add empty "return" dict, this is the standard for NULL returns */ > >>> + qdict_put_obj(rsp, "return", QOBJECT(qdict_new())); > >> Luiz, I know we decided to return empty dicts because it lets us extend > >> things better, but did we want to rule out the use of a 'null' return > >> value entirely? > > For asynchronous commands you mean? No we didn't. > > No, nothing to do with asynchronous commands. Just in general. > > The question is, is it legal for a command to return 'null'. It's > certain valid JSON, but is it valid QMP? No, it's not valid. > > Regards, > > Anthony Liguori > > > *iirc*, what happens today is that no command using this api is truly async, > > for two reasons. First, changing from sync to async can break clients (that > > happened to query-balloon). Second, although I can't remember the exact > > details, the api that exists in the tree today is limited. > > > > But for a new thing, like QAPI, having different semantics for async commands > > seems the right thing to be done (ie. delaying the response). > > > > >> For a command like this, I can't imagine ever wanting to extend the > >> return value... > >> > >> Regards, > >> > >> Anthony Liguori > >> > >>> } > >>> if (cmd->tag) { > >>> qdict_put_obj(rsp, "tag", cmd->tag); >