From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "fam@euphon.net" <fam@euphon.net>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"mst@redhat.com" <mst@redhat.com>,
"codyprime@gmail.com" <codyprime@gmail.com>,
"mark.cave-ayland@ilande.co.uk" <mark.cave-ayland@ilande.co.uk>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"armbru@redhat.com" <armbru@redhat.com>,
"kraxel@redhat.com" <kraxel@redhat.com>,
"mreitz@redhat.com" <mreitz@redhat.com>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
"quintela@redhat.com" <quintela@redhat.com>,
"david@redhat.com" <david@redhat.com>,
"mdroth@linux.vnet.ibm.com" <mdroth@linux.vnet.ibm.com>,
"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
"marcandre.lureau@redhat.com" <marcandre.lureau@redhat.com>,
"rth@twiddle.net" <rth@twiddle.net>,
"farman@linux.ibm.com" <farman@linux.ibm.com>,
"groug@kaod.org" <groug@kaod.org>,
"dgilbert@redhat.com" <dgilbert@redhat.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"stefanha@redhat.com" <stefanha@redhat.com>,
"jsnow@redhat.com" <jsnow@redhat.com>,
"david@gibson.dropbear.id.au" <david@gibson.dropbear.id.au>,
Kevin Wolf <kwolf@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"qemu-s390x@nongnu.org" <qemu-s390x@nongnu.org>,
"sundeep.lkml@gmail.com" <sundeep.lkml@gmail.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [RFC] error: auto propagated local_err
Date: Thu, 19 Sep 2019 15:49:48 +0100 [thread overview]
Message-ID: <20190919144948.GR20217@redhat.com> (raw)
In-Reply-To: <152afb5b-8efb-d968-d595-94f58ad02a04@redhat.com>
On Thu, Sep 19, 2019 at 09:44:14AM -0500, Eric Blake wrote:
> On 9/19/19 9:30 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> >>
> >> To the same topic, of minimization: should we always call MAKE_ERRP_SAFE at function top, or only
> >> in block, where it is needed (assume, we dereference it only inside some "if" or "while"?
> >> Kevin, is something bad in propagation, when it not related to error_abort?
> >>
> >>
> >
> > Or, even, we may use MAKE_ERRP_SAFE on every function, which have Error **errp argument, even if we neither
> > dereference it nor append hints? Is it what you propose by "SINGLE paradigm"? It's of course simpler to script,
> > to check in checkpatch and to maintain.
>
> Yes. The simpler we make the rules, and the less boilerplate it entails,
> the more likely that we can:
>
> a) avoid exceptions and corner cases that cost review time
> b) automate the conversion into complying with the rule
> c) codify those rules in syntax check to ensure they are followed
> post-conversion
>
> ALWAYS using MAKE_ERRP_SAFE() on entry to any function that has an Error
> **errp parameter is dirt-simple to explain. It has no performance
> penalty if the user passed in a normal error or error_abort (the cost of
> an 'if' hidden in the macro is probably negligible compared to
> everything else we do), and has no semantic penalty if the user passed
> in NULL or error_fatal (we now get the behavior we want with less
> boilerplate).
>
> Having to think 'does this method require me to use MAKE_ERRP_SAFE, or
> can I omit it?' does not provide the same simplicity.
The flipside is that MAKE_ERRP_SAFE hides a bunch of logic, so you don't
really know what its doing without looking at it, and this is QEMU
custom concept so one more thing to learn for new contributors.
While I think it is a nice trick, personally I think we would be better
off if we simply used a code pattern which does not require de-referencing
'errp' at all, aside from exceptional cases. IOW, no added macro in 95%
of all our methods using Error **errp.
There are lots of neat things we could do with auto-cleanup functions we
I think we need to be wary of hiding too much cleverness behind macros
when doing so overall.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2019-09-19 14:57 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
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é [this message]
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=20190919144948.GR20217@redhat.com \
--to=berrange@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@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=eblake@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).