All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: Peter Xu <peterx@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org, leiyang@redhat.com,
	marcandre.lureau@redhat.com,
	Markus Armbruster <armbru@redhat.com>,
	Michael Roth <michael.roth@amd.com>
Subject: Re: [PATCH v3 04/13] util/error: add &error_reporter
Date: Mon, 15 Sep 2025 19:29:41 +0100	[thread overview]
Message-ID: <aMhbFcvItNMBtQhN@redhat.com> (raw)
In-Reply-To: <c1907e57-d279-40fa-b181-3b54441c49d7@yandex-team.ru>

On Mon, Sep 15, 2025 at 09:14:18PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 15.09.25 18:45, Peter Xu wrote:
> > On Mon, Sep 15, 2025 at 04:22:01PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> > > Add a pair to &error_warn helper, to reduce the pattern like
> > > 
> > >      Error *local_err = NULL;
> > > 
> > >      ...
> > > 
> > >      if (!foo(..., &local_err)) {
> > >          error_report_err(local_err);
> > >          return false;
> > >      }
> > > 
> > > to simply
> > > 
> > >      if (!foo(..., &error_reporter)) {
> > >          return false;
> > >      }
> > > 
> > > Of course, for new interfaces, it's better to always support and handle
> > > errp argument. But when have to rework the old ones, it's not always
> > > feasible to convert everything to support/handle errp.
> > > 
> > > The new helper is used in following commits.
> > Could we add some explanation of why we need this if we already have
> > error_warn?
> > 
> > I don't see much difference except error_warn will prepend it with
> > "warning: ", but that doesn't sound like a real problem..
> 
> Yes, seems it's the only difference.
> 
> For me it seems strange to call it "warning", when we actually go to failure branch of the code logic.
> Finally, we do have error_report() and warn_report(). Seems not a problem to have corresponding "magic" variables.
> 
> If have only one special error variable to simply report the error, I'd prefer it not have "warning: " prefix.
> I.e. drop error_warn, and keep only error_reporter (or some better name?).

FWIW, this whole debate is liable to be a bit of a can of worms that
will delay your series from getting merged.

Can I suggest you repost this without &error_reporter usage, and then
have a separate standalone series that proposes error_report, and
converts a handful of files to demonstrate its usage.

With 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 :|



  reply	other threads:[~2025-09-15 18:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-15 13:21 [PATCH v3 00/13] io: deal with blocking/non-blocking fds Vladimir Sementsov-Ogievskiy
2025-09-15 13:21 ` [PATCH v3 01/13] char-socket: tcp_chr_recv(): drop extra _set_(block, cloexec) Vladimir Sementsov-Ogievskiy
2025-09-15 13:21 ` [PATCH v3 02/13] char-socket: tcp_chr_recv(): add comment Vladimir Sementsov-Ogievskiy
2025-09-15 13:22 ` [PATCH v3 03/13] util: add qemu_set_blocking() function Vladimir Sementsov-Ogievskiy
2025-09-15 13:22 ` [PATCH v3 04/13] util/error: add &error_reporter Vladimir Sementsov-Ogievskiy
2025-09-15 15:45   ` Peter Xu
2025-09-15 18:14     ` Vladimir Sementsov-Ogievskiy
2025-09-15 18:29       ` Daniel P. Berrangé [this message]
2025-09-15 18:40         ` Vladimir Sementsov-Ogievskiy
2025-09-17 13:51         ` Markus Armbruster
2025-09-15 13:22 ` [PATCH v3 05/13] handle result of qio_channel_set_blocking() Vladimir Sementsov-Ogievskiy
2025-09-15 17:04   ` Jag Raman
2025-09-15 18:32     ` Vladimir Sementsov-Ogievskiy
2025-09-15 13:22 ` [PATCH v3 06/13] migration: qemu_file_set_blocking(): add errp parameter Vladimir Sementsov-Ogievskiy
2025-09-15 13:22 ` [PATCH v3 07/13] util: drop qemu_socket_set_nonblock() Vladimir Sementsov-Ogievskiy
2025-09-15 13:22 ` [PATCH v3 08/13] util: drop qemu_socket_try_set_nonblock() Vladimir Sementsov-Ogievskiy
2025-09-15 13:22 ` [PATCH v3 09/13] io/channel-socket: rework qio_channel_socket_copy_fds() Vladimir Sementsov-Ogievskiy
2025-09-15 15:21   ` Daniel P. Berrangé
2025-09-15 13:22 ` [PATCH v3 10/13] util: drop qemu_socket_set_block() Vladimir Sementsov-Ogievskiy
2025-09-15 13:22 ` [PATCH v3 11/13] use qemu_set_blocking instead of g_unix_set_fd_nonblocking Vladimir Sementsov-Ogievskiy
2025-09-15 15:22   ` Daniel P. Berrangé
2025-09-15 13:22 ` [PATCH v3 12/13] chardev: qemu_chr_open_fd(): add errp Vladimir Sementsov-Ogievskiy
2025-09-15 15:23   ` Daniel P. Berrangé
2025-09-15 13:22 ` [PATCH v3 13/13] chardev: close an fd on failure path Vladimir Sementsov-Ogievskiy
2025-09-15 15:25   ` Daniel P. Berrangé

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=aMhbFcvItNMBtQhN@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=leiyang@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=michael.roth@amd.com \
    --cc=peterx@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@yandex-team.ru \
    /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.