qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Fam Zheng <famz@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] nvme: Make nvme_init error handling code more readable
Date: Fri, 25 May 2018 08:07:24 -0500	[thread overview]
Message-ID: <f89ee2a6-03e1-ee56-4d7d-e6d0d513094d@redhat.com> (raw)
In-Reply-To: <20180525062503.GE28589@lemon.usersys.redhat.com>

On 05/25/2018 01:25 AM, Fam Zheng wrote:

>>> And that makes five labels in total, I'm not sure I like it:
>>>
>>> fail_handler:
>>>      aio_set_event_notifier(bdrv_get_aio_context(bs), &s->irq_notifier,
>>>                             false, NULL, NULL);
>>> fail_queue:
>>>      nvme_free_queue_pair(bs, s->queues[0]);
>>> fail_regs:
>>>      qemu_vfio_pci_unmap_bar(s->vfio, 0, (void *)s->regs, 0, NVME_BAR_SIZE);
>>> fail_vfio:
>>>      qemu_vfio_close(s->vfio);
>>> fail:
>>>      g_free(s->queues);
>>>      event_notifier_cleanup(&s->irq_notifier);
>>>      return ret;
>>
>> Doesn't look materially worse to me :)
> 
> The labels themselves are not ugly or bad, but the goto statements above will be
> harder to manage.
> 
>>
>> With nice cleanup functions that detect "hasn't been set up" and do
>> nothing then, like free(NULL), you can use just one label.  Sadly,
>> cleanup functions are often not nice that way.
> 
> nvme_free_queue_pair and qemu_vfio_close are cleanup functions and we can
> improve them, but to make qemu_vfio_pci_unmap_bar behave similarly is just odd:
> it's not a clean up function, at least not for s->vfio.

But even then, you can do:

fail:
     if (s->vfio) {
         qemu_vfio_close(s->vfio);
     }

That is, there are ways to make a single cleanup path more applicable, 
regardless of where you decided you needed an early cleanup.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

      parent reply	other threads:[~2018-05-25 13:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21  6:35 [Qemu-devel] [PATCH] nvme: Make nvme_init error handling code more readable Fam Zheng
2018-05-21  8:35 ` Peter Maydell
2018-05-21  8:56   ` Fam Zheng
2018-05-24 17:16 ` Paolo Bonzini
2018-05-25  2:16   ` Fam Zheng
2018-05-25  5:47     ` Markus Armbruster
2018-05-25  6:25       ` Fam Zheng
2018-05-25  7:27         ` Markus Armbruster
2018-05-25 13:07         ` Eric Blake [this message]

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=f89ee2a6-03e1-ee56-4d7d-e6d0d513094d@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).