All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Vladimir Sementsov-Ogievskiy" <vsementsov@virtuozzo.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: Questionable aspects of QEMU Error's design
Date: Fri, 03 Jul 2020 14:21:07 +0200	[thread overview]
Message-ID: <874kqooklo.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <87blo7heag.fsf@dusky.pond.sub.org> (Markus Armbruster's message of "Sat, 04 Apr 2020 09:59:35 +0200")

Markus Armbruster <armbru@redhat.com> writes:

> Markus Armbruster <armbru@redhat.com> writes:
>
>> QEMU's Error was patterned after GLib's GError.  Differences include:
> [...]
>> * Return value conventions
>>
>>   Common: non-void functions return a distinct error value on failure
>>   when such a value can be defined.  Patterns:
>>
>>   - Functions returning non-null pointers on success return null pointer
>>     on failure.
>>
>>   - Functions returning non-negative integers on success return a
>>     negative error code on failure.
>>
>>   Different: GLib discourages void functions, because these lead to
>>   awkward error checking code.  We have tons of them, and tons of
>>   awkward error checking code:
>>
>>     Error *err = NULL;
>>     frobnicate(arg, &err);
>>     if (err) {
>>         ... recover ...
>>         error_propagate(errp, err);
>>     }
>>
>>   instead of
>>
>>     if (!frobnicate(arg, errp))
>>         ... recover ...
>>     }
>>
>>   Can also lead to pointless creation of Error objects.
>>
>>   I consider this a design mistake.  Can we still fix it?  We have more
>>   than 2000 void functions taking an Error ** parameter...
>>
>>   Transforming code that receives and checks for errors with Coccinelle
>>   shouldn't be hard.  Transforming code that returns errors seems more
>>   difficult.  We need to transform explicit and implicit return to
>>   either return true or return false, depending on what we did to the
>>   @errp parameter on the way to the return.  Hmm.
> [...]
>
> To figure out what functions with an Error ** parameter return, I used
> Coccinelle to find such function definitions and print the return types.
> Summary of results:
>
>    2155 void
>     873 signed integer
>     494 pointer
>     153 bool
>      33 unsigned integer
>       6 enum
>    ---------------------
>    3714 total

With my "[PATCH v2 00/44] Less clumsy error checking" applied, I now count

     1946 void
      879 signed integer
      484 pointer
      301 bool
       33 unsigned integer
        3 GuestFsfreezeStatus
        1 gnutls_x509_crt_t
        1 QCryptoCipherAlgorithm
        1 COLOMessage
        1 BlockdevDetectZeroesOptions
     ---------------------
     3650 total

About 7% complete for function definitions.

> I then used Coccinelle to find checked calls of void functions (passing
> &error_fatal or &error_abort is not considered "checking" here).  These
> calls become simpler if we make the functions return a useful value.  I
> found a bit under 600 direct calls, and some 50 indirect calls.

Different method this time: I count any direct function call that takes
&err other than &error_abort, &error_fatal, and whose value, if any, is
not used.

Current master: 1050

With my "[PATCH v2 00/44] Less clumsy error checking" applied: 649

About 38% complete for function calls.

> Most frequent direct calls:
>
>     127 object_property_set_bool
>      27 qemu_opts_absorb_qdict
>      16 visit_type_str
>      14 visit_type_int
>      10 visit_type_uint32

Top scorers master:

    151 sysbus_realize()
     34 qemu_opts_absorb_qdict()
     29 visit_type_int()
     24 visit_type_str()
     23 cpu_exec_realizefn()
     19 visit_type_size()
     16 qdev_realize()
     14 visit_type_bool()
     12 visit_type_uint32()
     11 visit_type_int32()
     11 object_property_set_bool()
     10 object_property_set_uint()
     10 object_property_set_int()
    +420 functions with fewer than 10 calls

Top scorers with my patches applied:

     23 cpu_exec_realizefn()
     15 visit_type_int()
     10 visit_type_size()
    +387 functions with fewer than 10 calls

Looks like this is going to be a long slog.

With functions into buckets by same name prefix up to the first '_':

     63 visit
     57 qmp
     33 bdrv
     29 cpu
     26 xen
     25 memory
   +113 buckets with fewer than 25 calls

[...]
>
> Please understand these are rough numbers from quick & dirty scripts.

Still are.



      parent reply	other threads:[~2020-07-03 12:22 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01  9:02 Questionable aspects of QEMU Error's design Markus Armbruster
2020-04-01 12:10 ` Vladimir Sementsov-Ogievskiy
2020-04-01 12:14   ` Vladimir Sementsov-Ogievskiy
2020-04-01 14:01   ` Alex Bennée
2020-04-01 15:49     ` Markus Armbruster
2020-04-01 15:05   ` Markus Armbruster
2020-04-01 12:44 ` Daniel P. Berrangé
2020-04-01 12:47   ` Vladimir Sementsov-Ogievskiy
2020-04-01 15:34   ` Markus Armbruster
2020-04-01 20:15 ` Peter Maydell
2020-04-02  5:31   ` Vladimir Sementsov-Ogievskiy
2020-04-02  9:36     ` BALATON Zoltan
2020-04-02 14:11       ` Vladimir Sementsov-Ogievskiy
2020-04-02 14:34         ` Markus Armbruster
2020-04-02 15:28           ` BALATON Zoltan
2020-04-03  7:09             ` Markus Armbruster
2020-04-02  5:54   ` Markus Armbruster
2020-04-02  6:11     ` Vladimir Sementsov-Ogievskiy
2020-04-02  8:11       ` Peter Maydell
2020-04-02  8:49         ` Daniel P. Berrangé
2020-04-02  8:55         ` Markus Armbruster
2020-04-02 14:35           ` Vladimir Sementsov-Ogievskiy
2020-04-02 15:06             ` Markus Armbruster
2020-04-02 17:17               ` Vladimir Sementsov-Ogievskiy
2020-04-03  7:48                 ` Markus Armbruster
2020-04-02 18:57           ` Paolo Bonzini
2020-04-02  8:47     ` Daniel P. Berrangé
2020-04-02  9:19       ` Alex Bennée
2020-04-02 14:33     ` Eric Blake
2020-04-04  7:59 ` Markus Armbruster
2020-04-04 10:59   ` Markus Armbruster
2020-04-06 14:05     ` Eduardo Habkost
2020-04-06 14:38       ` Eduardo Habkost
2020-04-06 14:10     ` Daniel P. Berrangé
2020-04-27 15:36   ` Markus Armbruster
2020-04-28  5:20     ` Vladimir Sementsov-Ogievskiy
2020-05-14  7:59       ` Vladimir Sementsov-Ogievskiy
2020-05-15  4:28         ` Markus Armbruster
2020-07-03  7:38           ` Markus Armbruster
2020-07-03  9:07             ` Vladimir Sementsov-Ogievskiy
2020-07-03 12:21   ` Markus Armbruster [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=874kqooklo.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --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 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.