WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 5/7] libxl_qmp, Return the callback return code i

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 5/7] libxl_qmp, Return the callback return code in qmp_next.
From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Date: Fri, 7 Oct 2011 16:23:17 +0100
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 07 Oct 2011 08:24:57 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=HFXc3943Ct6M6PHsRyaeKl/cHqLFhA4oBygaZlqVfM8=; b=oPH6DLUvAGWFaDK9uMHkLT7+y9PPBYi3X4GO+H1FB0k0Zw7P6WinBd3QYbTO2GffgQ mVSwDO2lYcgs7sliemAJpYcQb17O+53ngVflPo+IQ0UzyF2WCCVk5cym1w9fglIhyC31 TP+mI0/kDPOV+YZEFmKKX9VmhKF14BD/9N6cg=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1317990988.21903.339.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1317989418-25463-1-git-send-email-anthony.perard@xxxxxxxxxx> <1317989418-25463-6-git-send-email-anthony.perard@xxxxxxxxxx> <1317990988.21903.339.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, Oct 7, 2011 at 13:36, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2011-10-07 at 13:10 +0100, Anthony PERARD wrote:
>> So, if there is an error in the answer given by QEMU, the function
>> qmp_synchronous_send while know.
>                       "will"
>
>>
>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>> ---
>>  tools/libxl/libxl_qmp.c |   14 ++++++++------
>>  1 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
>> index 1594a4f..cd3e4e4 100644
>> --- a/tools/libxl/libxl_qmp.c
>> +++ b/tools/libxl/libxl_qmp.c
>> @@ -233,6 +233,7 @@ static int qmp_handle_response(libxl__qmp_handler *qmp,
>>                                 const libxl__json_object *resp)
>>  {
>>      libxl__qmp_message_type type = LIBXL__QMP_MESSAGE_TYPE_INVALID;
>> +    int rc = 0;
>>
>>      type = qmp_response_type(qmp, resp);
>>      LIBXL__LOG(qmp->ctx, LIBXL__LOG_DEBUG,
>> @@ -241,14 +242,14 @@ static int qmp_handle_response(libxl__qmp_handler *qmp,
>>      switch (type) {
>>      case LIBXL__QMP_MESSAGE_TYPE_QMP:
>>          /* On the greeting message from the server, enable QMP capabilities 
>> */
>> -        enable_qmp_capabilities(qmp);
>> +        rc = enable_qmp_capabilities(qmp);
>>          break;
>>      case LIBXL__QMP_MESSAGE_TYPE_RETURN: {
>>          callback_id_pair *pp = qmp_get_callback_from_id(qmp, resp);
>>
>>          if (pp) {
>>              if (pp->callback) {
>> -                pp->callback(qmp,
>> +                rc = pp->callback(qmp,
>>                               libxl__json_map_get("return", resp, JSON_ANY),
>>                               pp->opaque);
>>              }
>> @@ -263,13 +264,13 @@ static int qmp_handle_response(libxl__qmp_handler *qmp,
>>      }
>>      case LIBXL__QMP_MESSAGE_TYPE_ERROR:
>>          qmp_handle_error_response(qmp, resp);
>> -        break;
>> +        return -1;
>
> A mixture or "return -1" and a rc variable returned at the outermost
> level is a bit odd. You should either always set rc and fall through or
> always return at the end of each case.

OK, I will change that.

>>      case LIBXL__QMP_MESSAGE_TYPE_EVENT:
>>          break;
>>      case LIBXL__QMP_MESSAGE_TYPE_INVALID:
>>          return -1;
>>      }
>> -    return 0;
>> +    return rc;
>>  }
>>
>>  /*
>> @@ -358,6 +359,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler 
>> *qmp)
>>
>>      char *incomplete = NULL;
>>      size_t incomplete_size = 0;
>> +    int rc = 0;
>>
>>      do {
>>          fd_set rfds;
>> @@ -416,7 +418,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler 
>> *qmp)
>>                  s = end + 2;
>>
>>                  if (o) {
>> -                    qmp_handle_response(qmp, o);
>> +                    rc = qmp_handle_response(qmp, o);
>
> If rc now indicates error do we need to bail straight away or need to
> keep going around this loop? (Or is it certain we will immediately fall
> out of the loop after this?)

We can not be sure that we will return, because it could be another
message in the butffer. So I should return if there is a protocol
error. But I think that I should keep seperate the return code of a
callback, so only the interested function (qmp_synchronous_send) will
read it (and return to the caller).

>>                      libxl__json_object_free(gc, o);
>>                  } else {
>>                      LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR,
>> @@ -429,7 +431,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler 
>> *qmp)
>>          } while (s < s_end);
>>     } while (s < s_end);
>>
>> -    return 1;
>> +    return rc;
>>  }
>>
>>  static int qmp_send(libxl__qmp_handler *qmp,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>