On Fri, 25 Mar 2011 16:22:16 -0500 Anthony Liguori <aligu...@us.ibm.com> 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<mdr...@linux.vnet.ibm.com> > > --- > > 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. *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); >