All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Claudio Fontana" <cfontana@suse.de>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Kevin Wolf" <kwolf@redhat.com>,
	qemu-devel@nongnu.org, dinechin@redhat.com,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [PATCH v4 2/3] module: add Error arguments to module_load_one and module_load_qom_one
Date: Thu, 22 Sep 2022 11:38:42 +0200	[thread overview]
Message-ID: <87leqb4ul9.fsf@pond.sub.org> (raw)
In-Reply-To: <Yywcs7CpKDxahOSM@redhat.com> ("Daniel P. Berrangé"'s message of "Thu, 22 Sep 2022 09:28:35 +0100")

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
>> Ease of use matters, too.  When sticking to the rule leads to awkward
>> code, we should stop and think.  Should we deviate from the rule?  Or
>> can we avoid that by tweaking the interface?
>> 
>> Philippe's proposed interface sticks to the rule.
>
> The cost is that when you see a  function   dosomething(true|false) as
> a reader you often have no idea what the effect of true vs false is
> on the behaviour of that function. You resort to looking at the
> API docs and/or code.  This is where C would really benefit from
> having named parameters like as  dosomething(ignore_errors=true|false)
> is totally obvious. Anyway, I digress.

Right.  Quoting myself: "If having to pass a flag turns out to to be a
legibility issue, we can have wrapper functions."  :)

>> Another interface that does: return -1 for error, 0 for module not found
>> (no error), and 1 for loaded.
>
> IMHO this pattern is generally easier to understand when looking at
> the callers, as the fatal error scenario is always clear.
>
> That said I would suggest neither approach as the public facing
> API. Rather stop trying to overload 3 states onto an error reporting
> pattern that inherantly wants to be 2 states. Instead just have
> distinct methods

Like these:

>   bool module_load_one(const char *prefix, const char *name, Error *errp)
>   bool module_try_load_one(const char *prefix, const char *name, Error *errp)
>
> other names are available for the second, eg module_load_one_optional()

module_load_one_if_there()?

By the way, the "one" in "module_load_one" & friends feels redundant.
When I see "module_load", I assume it loads one module.

> Internally, both would call into a common helper following either
> Philippe's idea, or the -1/0/1 int return value. Either is fine,
> as they won't be exposed to any caller.

Yup.



  parent reply	other threads:[~2022-09-22 10:54 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08 18:30 [PATCH v4 0/3] improve error handling for module load Claudio Fontana
2022-09-08 18:30 ` [PATCH v4 1/3] module: removed unused function argument "mayfail" Claudio Fontana
2022-09-08 18:30 ` [PATCH v4 2/3] module: add Error arguments to module_load_one and module_load_qom_one Claudio Fontana
2022-09-15  8:43   ` Claudio Fontana
2022-09-16  8:13   ` Richard Henderson
2022-09-16  8:16     ` Claudio Fontana
2022-09-16  9:27   ` Markus Armbruster
2022-09-16 10:48     ` Claudio Fontana
2022-09-16 14:26       ` Markus Armbruster
2022-09-16 15:06         ` Claudio Fontana
2022-09-19  8:17           ` Markus Armbruster
2022-09-19  8:45             ` Claudio Fontana
2022-09-21 12:47               ` Markus Armbruster
2022-09-19 10:18     ` Philippe Mathieu-Daudé via
2022-09-21 12:16       ` Markus Armbruster
2022-09-21 16:03         ` Claudio Fontana
2022-09-22  6:07           ` Markus Armbruster
2022-09-22  8:28             ` Daniel P. Berrangé
2022-09-22  9:20               ` Claudio Fontana
2022-09-22  9:21                 ` Claudio Fontana
2022-09-22  9:27                   ` Claudio Fontana
2022-09-22  9:31                 ` Daniel P. Berrangé
2022-09-22  9:34                   ` Claudio Fontana
2022-09-22 10:37                     ` Daniel P. Berrangé
2022-09-22 12:30                       ` Claudio Fontana
2022-09-22 12:33                         ` Daniel P. Berrangé
2022-09-22 12:35                           ` Claudio Fontana
2022-09-22  9:38               ` Markus Armbruster [this message]
2022-09-22  9:43                 ` Claudio Fontana
2022-09-22 12:42                   ` Markus Armbruster
2022-09-22 12:45                     ` Claudio Fontana
2022-09-22 13:20                       ` Markus Armbruster
2022-09-22 13:33                         ` Claudio Fontana
2022-09-22 14:36                           ` Markus Armbruster
2022-09-22 15:22                             ` Claudio Fontana
2022-09-23  5:31                               ` Markus Armbruster
2022-09-23  9:40                                 ` Claudio Fontana
2022-09-22 13:34                         ` Philippe Mathieu-Daudé via
2022-09-22 13:42                           ` Claudio Fontana
2022-09-22 13:44                           ` Daniel P. Berrangé
2022-09-22 14:01                             ` Claudio Fontana
2022-09-22 14:54                     ` Kevin Wolf
2022-09-22 15:08                       ` Claudio Fontana
2022-09-22 15:27                       ` Markus Armbruster
2022-09-22 15:51                         ` Claudio Fontana
2022-09-22 17:05                         ` Kevin Wolf
2022-09-23  9:42                           ` Claudio Fontana
2022-09-23  9:44                           ` Claudio Fontana
2022-09-25 10:35           ` Richard Henderson
2022-09-08 18:30 ` [PATCH v4 3/3] accel: abort if we fail to load the accelerator plugin Claudio Fontana

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=87leqb4ul9.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=cfontana@suse.de \
    --cc=dinechin@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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.