qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Lieven <pl@kamp.de>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Benoît Canet" <benoit.canet@irqsave.net>,
	"Kevin Wolf" <kwolf@redhat.com>, "Fam Zheng" <famz@redhat.com>,
	"ronnie sahlberg" <ronniesahlberg@gmail.com>,
	"Jeff Cody" <jcody@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Max Reitz" <mreitz@redhat.com>,
	"Orit Wasserman" <owasserm@redhat.com>,
	"Federico Simoncelli" <fsimonce@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Wenchao Xia" <xiawenc@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCHv7 1/5] block: add native support for NFS
Date: Fri, 31 Jan 2014 12:16:38 +0100	[thread overview]
Message-ID: <52EB8616.4020005@kamp.de> (raw)
In-Reply-To: <CAJSP0QV6nsseaRbyni3jerBsWvFE1tQtLsQX8mFSTJO71aS_wg@mail.gmail.com>

On 31.01.2014 11:46, Stefan Hajnoczi wrote:
> On Fri, Jan 31, 2014 at 10:11 AM, Peter Lieven <pl@kamp.de> wrote:
>> On 31.01.2014 09:57, Stefan Hajnoczi wrote:
>>> On Thu, Jan 30, 2014 at 10:35 PM, Peter Lieven <pl@kamp.de> wrote:
>>>> Am 30.01.2014 um 15:22 schrieb Stefan Hajnoczi <stefanha@gmail.com>:
>>>>
>>>>> On Wed, Jan 29, 2014 at 05:19:59PM +0100, Benoīt Canet wrote:
>>>>>> Le Wednesday 29 Jan 2014 ą 09:50:21 (+0100), Peter Lieven a écrit :
>>>>>>> +static int nfs_file_open(BlockDriverState *bs, QDict *options, int
>>>>>>> flags,
>>>>>>> +                         Error **errp) {
>>>>>>> +    NFSClient *client = bs->opaque;
>>>>>>> +    int64_t ret;
>>>>>>> +    QemuOpts *opts;
>>>>>>> +    Error *local_err = NULL;
>>>>>>> +
>>>>>>> +    opts = qemu_opts_create(&runtime_opts, NULL, 0, &error_abort);
>>>>>>> +    qemu_opts_absorb_qdict(opts, options, &local_err);
>>>>>>> +    if (error_is_set(&local_err)) {
>>>>>>> +        qerror_report_err(local_err);
>>>>>> I have seen more usage of error_propagate(errp, local_err); in QEMU
>>>>>> code.
>>>>>> Maybe I am missing the point.
>>>>> Yes, I think you are right.  The Error should be propagated to the
>>>>> caller.  It's not clear to me whether we can ever get an error from
>>>>> qemu_opts_absorb_qdict() in this call site though.
>>>> Is there any action I should take here? If yes, can you advise what
>>>> to do please.
>>> The issue is that nfs_file_open() takes an Error **errp argument.
>>> This means the function should report detailed errors using the Error
>>> object.
>>>
>>> The patch prints and then discards the local_error instead of
>>> propagating it to the caller's errp.
>>>
>>> We should just propagate the error instead of printing it:
>>> if (error_is_set(&local_err)) {
>>>       error_propagate(errp, local_err);
>>>       goto ...;
>>
>> Ok, you are just referring to this part in nfs_file_open:
>>
>>      if (error_is_set(&local_err)) {
>>          qerror_report_err(local_err);
>>          error_free(local_err);
>>          return -EINVAL;
>>      }
>>
>> which I would change to:
>>
>>      if (error_is_set(&local_err)) {
>>          error_propagate(errp, local_err);
>>          return -EINVAL;
>>      }
> Yes.
>
>> The use of error_setg in nfs_client_open is ok?
> Yes, it's fine.
>
> The Error API is not 100% obvious when you first see it, but once you
> learn the conventions it's pretty usable:
>
> Functions take an Error **errp argument.  This argument is optional,
> so a caller that doesn't care about detailed error messages may pass
> NULL.  This has implications...
>
> error_setg(errp, fmt, ...) handles errp == NULL internally so you can
> call it unconditionally.
>
> The tricky thing is that error_is_set() only works if errp is non-NULL
> (otherwise error_setg() skips creating an Error object).  So it means
> you cannot rely on your errp argument and often functions will declare
> Error *local_err = NULL, so they can pass &local_err to child
> functions.  Finally, error_propagate(errp, local_err) is used to pass
> out the Error object to our caller.
>
> Hope this summary makes the Error API clear.
>
> Stefan
Thanks for the explanation. I will sent you an updated series shortly.

Peter


-- 

Mit freundlichen Grüßen

Peter Lieven

...........................................................

   KAMP Netzwerkdienste GmbH
   Vestische Str. 89-91 | 46117 Oberhausen
   Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
   pl@kamp.de | http://www.kamp.de

   Geschäftsführer: Heiner Lante | Michael Lante
   Amtsgericht Duisburg | HRB Nr. 12154
   USt-Id-Nr.: DE 120607556

...........................................................

  reply	other threads:[~2014-01-31 11:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-29  8:50 [Qemu-devel] [PATCHv7 0/5] block: add native support for NFS Peter Lieven
2014-01-29  8:50 ` [Qemu-devel] [PATCHv7 1/5] " Peter Lieven
2014-01-29 16:19   ` Benoît Canet
2014-01-29 16:38     ` Peter Lieven
2014-01-30  9:05       ` Stefan Hajnoczi
2014-01-30  9:12         ` Peter Lieven
2014-01-30 14:23           ` Stefan Hajnoczi
2014-01-30 21:33             ` Peter Lieven
2014-01-30 14:22     ` Stefan Hajnoczi
2014-01-30 21:35       ` Peter Lieven
2014-01-31  8:57         ` Stefan Hajnoczi
2014-01-31  9:11           ` Peter Lieven
2014-01-31 10:46             ` Stefan Hajnoczi
2014-01-31 11:16               ` Peter Lieven [this message]
2014-01-31 11:36     ` Peter Lieven
2014-01-29  8:50 ` [Qemu-devel] [PATCHv7 2/5] qemu-iotests: change _supported_proto to file for various tests Peter Lieven
2014-01-29  8:50 ` [Qemu-devel] [PATCHv7 3/5] qemu-iotests: enable support for NFS protocol Peter Lieven
2014-01-29  8:50 ` [Qemu-devel] [PATCHv7 4/5] qemu-iotests: enable test 016 and 025 to work with " Peter Lieven
2014-01-29  8:50 ` [Qemu-devel] [PATCHv7 5/5] qemu-iotests: blacklist test 020 for " Peter Lieven
2014-01-29 13:59 ` [Qemu-devel] [PATCHv7 0/5] block: add native support for NFS Stefan Hajnoczi
2014-01-29 14:13   ` Peter Lieven
2014-01-29 14:22   ` Peter Lieven
2014-01-29 14:26     ` Peter Lieven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52EB8616.4020005@kamp.de \
    --to=pl@kamp.de \
    --cc=benoit.canet@irqsave.net \
    --cc=famz@redhat.com \
    --cc=fsimonce@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=owasserm@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    --cc=xiawenc@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).