All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org, "Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH v2] hw/core/qdev: Increase qdev_realize() kindness
Date: Mon, 06 Jul 2020 09:09:27 +0200	[thread overview]
Message-ID: <87fta5glw8.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20200705221430.30207-1-f4bug@amsat.org> ("Philippe Mathieu-Daudé"'s message of "Mon, 6 Jul 2020 00:14:30 +0200")

Philippe Mathieu-Daudé <f4bug@amsat.org> writes:

> Since commit 510ef98dca5, qdev_realize() aborts if bus-less
> device is realized on a bus. Be kind with the developer by
> displaying a hint about what is wrong.
>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> v2: Use errp (bonzini suggestion)
>
> Paolo, I was tempted to check errp is really &error_abort else
> it is an error! :P
>
>     } else if (DEVICE_GET_CLASS(dev)->bus_type) {
>         error_setg(errp, "%s: Unexpected bus '%s' for bus-less device '%s'",
>                    __func__, DEVICE_GET_CLASS(dev)->bus_type,
>                    object_get_typename(OBJECT(dev)));
>         assert(errp == &error_abort); // <--------------

Don't!

Functions taking an Error **errp parameter to report errors should never
examine the argument.

The Error API is for separating concerns.  The callee's concern is
detecting errors and failing cleanly.  *Handling* the errors is the
caller's concern.

To simplify common handling patterns, we provide convenience arguments
&error_abort, &error_fatal, and NULL.  Their use is exclusively the
caller's concern.

Examining the argument undermines the separation of concerns.

>         return false;
>     }
> ---
>  hw/core/qdev.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index 2131c7f951..9d1530c39d 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -392,8 +392,11 @@ bool qdev_realize(DeviceState *dev, BusState *bus, Error **errp)
>  
>      if (bus) {
>          qdev_set_parent_bus(dev, bus);
> -    } else {
> -        assert(!DEVICE_GET_CLASS(dev)->bus_type);
> +    } else if (DEVICE_GET_CLASS(dev)->bus_type) {
> +        error_setg(errp, "%s: Unexpected bus '%s' for bus-less device '%s'",
> +                   __func__, DEVICE_GET_CLASS(dev)->bus_type,
> +                   object_get_typename(OBJECT(dev)));
> +        return false;
>      }
>  
>      object_property_set_bool(OBJECT(dev), true, "realized", &err);

Scratch __func__.  error_setg() records __FILE__, __LINE__ and __func__,
and error_handle_fatal() prints them.

Always, always, always test your error messages.  If they are impossible
to test, mock up the error.  If mocking up is too much trouble, then
reporting the error nicely is, too.

That said, this one matters to me only insofar as it sets a bad example.
I don't actually care how impossible error messages come out :)



  reply	other threads:[~2020-07-06  7:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-05 22:14 [PATCH v2] hw/core/qdev: Increase qdev_realize() kindness Philippe Mathieu-Daudé
2020-07-06  7:09 ` Markus Armbruster [this message]
2020-07-06  8:20   ` Philippe Mathieu-Daudé

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=87fta5glw8.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=pbonzini@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.