From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: fam@euphon.net, peter.maydell@linaro.org, mst@redhat.com,
codyprime@gmail.com, mark.cave-ayland@ilande.co.uk,
qemu-devel@nongnu.org, armbru@redhat.com, kraxel@redhat.com,
mreitz@redhat.com, qemu-block@nongnu.org, quintela@redhat.com,
david@redhat.com, mdroth@linux.vnet.ibm.com, pasic@linux.ibm.com,
borntraeger@de.ibm.com, marcandre.lureau@redhat.com,
rth@twiddle.net, farman@linux.ibm.com, groug@kaod.org,
dgilbert@redhat.com, alex.williamson@redhat.com,
qemu-arm@nongnu.org, stefanha@redhat.com, jsnow@redhat.com,
david@gibson.dropbear.id.au,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
berrange@redhat.com, cohuck@redhat.com, qemu-s390x@nongnu.org,
sundeep.lkml@gmail.com, qemu-ppc@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC] error: auto propagated local_err
Date: Thu, 19 Sep 2019 08:40:58 -0500 [thread overview]
Message-ID: <57483252-273c-4606-47a8-eddeb840109a@redhat.com> (raw)
In-Reply-To: <20190919091720.GB10163@localhost.localdomain>
On 9/19/19 4:17 AM, Kevin Wolf wrote:
> Am 18.09.2019 um 19:10 hat Eric Blake geschrieben:
>> On 9/18/19 8:02 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> + */
>>> +#define MAKE_ERRP_SAFE(errp) \
>>> +g_auto(ErrorPropagationStruct) (__auto_errp_prop) = {.errp = (errp)}; \
>>> +if ((errp) == NULL || *(errp) == error_abort || *(errp) == error_fatal) { \
>>> + (errp) = &__auto_errp_prop.local_err; \
>>> +}
>>
>> Not written to take a trailing semicolon in the caller.
>>
>> You could even set __auto_errp_prop unconditionally rather than trying
>> to reuse incoming errp (the difference being that error_propagate() gets
>> called more frequently).
>
> I think this difference is actually a problem.
>
> When debugging things, I hate error_propagate(). It means that the Error
> (specifically its fields src/func/line) points to the outermost
> error_propagate() rather than the place where the error really happened.
> It also makes error_abort completely useless because at the point where
> the process gets aborted, the interesting information is already lost.
Okay, based on that, I see the following desirable semantics:
Caller: one of 4 calling paradigms:
pass errp=NULL (we don't care about failures)
pass errp=&error_abort (we want to abort() as soon as possible as close
to the real problem as possible)
pass errp=&error_fatal (we want to exit(), but only after collecting as
much information as possible)
pass errp = anything else (we are collecting an error for other reasons,
we may report it or let the caller decide or ...)
Callee: we want a SINGLE paradigm:
func (Error **errp)
{
MAKE_ERRP_SAFE();
now we can pass errp to any child function, test '*errp', or do
anything else, and we DON'T have to call error_propagate.
I think that means we need:
#define MAKE_ERRP_SAFE() \
g_auto(...) __auto_errp = { .errp = errp }; \
do { \
if (!errp || errp == &error_fatal) { errp = &__auto_errp.local; } \
} while (0)
So back to the caller semantics:
if the caller passed NULL, we've redirected errp locally so that we can
use *errp at will; the auto-cleanup will free our local error.
if the caller passed &error_abort, we keep errp unchanged. *errp tests
will never trigger, because we'll have already aborted in the child on
the original errp, giving developers the best stack trace.
if the caller passed &error_fatal, we redirect errp. auto-cleanup will
then error_propagate that back to the caller, producing as much nice
information as possible.
if the caller passed anything else, we keep errp unchanged, so no extra
error_propagate in the mix.
>
> So I'd really like to restrict the use of error_propagate() to places
> where it's absolutely necessary. Unless, of course, you can fix these
> practical problems that error_propagate() causes for debugging.
>
> In fact, in the context of Greg's series, I think we really only need to
> support hints for error_fatal, which are cases that users are supposed
> to see. We should exclude error_abort in MAKE_ERRP_SAFE() because these
> are things that are never supposed to happen. A good stack trace is more
> important there than adding a hint to the message.
We also want to handle the caller passing NULL, so that we no longer
have to introduce 'Error *local_error = NULL' everywhere.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2019-09-19 13:58 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 13:02 [Qemu-devel] [RFC] error: auto propagated local_err Vladimir Sementsov-Ogievskiy
2019-09-18 17:10 ` Eric Blake
2019-09-18 17:46 ` Vladimir Sementsov-Ogievskiy
2019-09-18 18:05 ` Eric Blake
2019-09-18 18:32 ` Eric Blake
2019-09-19 6:47 ` Vladimir Sementsov-Ogievskiy
2019-09-19 13:29 ` Eric Blake
2019-09-19 9:17 ` Kevin Wolf
2019-09-19 9:47 ` Vladimir Sementsov-Ogievskiy
2019-09-19 10:09 ` Daniel P. Berrangé
2019-09-19 10:21 ` Vladimir Sementsov-Ogievskiy
2019-09-19 11:55 ` Daniel P. Berrangé
2019-09-19 12:00 ` Vladimir Sementsov-Ogievskiy
2019-09-19 13:03 ` Kevin Wolf
2019-09-19 13:17 ` Vladimir Sementsov-Ogievskiy
2019-09-19 13:44 ` Eric Blake
2019-09-19 13:40 ` Eric Blake [this message]
2019-09-19 14:13 ` Vladimir Sementsov-Ogievskiy
2019-09-19 14:26 ` Eric Blake
2019-09-19 14:30 ` Vladimir Sementsov-Ogievskiy
2019-09-19 14:44 ` Eric Blake
2019-09-19 14:49 ` Daniel P. Berrangé
2019-09-19 15:24 ` Eric Blake
2019-09-19 15:37 ` Vladimir Sementsov-Ogievskiy
2019-09-19 15:50 ` Daniel P. Berrangé
2019-09-19 16:16 ` Vladimir Sementsov-Ogievskiy
2019-09-19 16:51 ` Daniel P. Berrangé
2019-09-20 12:58 ` Eric Blake
2019-09-19 15:12 ` Vladimir Sementsov-Ogievskiy
2019-09-19 14:34 ` Kevin Wolf
2019-09-19 1:54 ` [Qemu-devel] " no-reply
2019-09-19 7:32 ` David Hildenbrand
2019-09-19 7:41 ` Vladimir Sementsov-Ogievskiy
2019-09-19 7:53 ` David Hildenbrand
2019-09-19 8:20 ` Vladimir Sementsov-Ogievskiy
2019-09-19 8:23 ` David Hildenbrand
2019-09-19 8:59 ` Greg Kurz
2019-09-19 9:28 ` Vladimir Sementsov-Ogievskiy
2019-09-19 10:08 ` Greg Kurz
2019-09-19 8:59 ` Max Reitz
2019-09-19 9:14 ` Vladimir Sementsov-Ogievskiy
2019-09-19 9:33 ` Max Reitz
2019-09-19 10:03 ` Vladimir Sementsov-Ogievskiy
2019-09-19 11:52 ` Max Reitz
2019-09-20 11:46 ` Vladimir Sementsov-Ogievskiy
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=57483252-273c-4606-47a8-eddeb840109a@redhat.com \
--to=eblake@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=codyprime@gmail.com \
--cc=cohuck@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=fam@euphon.net \
--cc=farman@linux.ibm.com \
--cc=groug@kaod.org \
--cc=jsnow@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=stefanha@redhat.com \
--cc=sundeep.lkml@gmail.com \
--cc=vsementsov@virtuozzo.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).