U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@cherry.de>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH] log: Add helpers for calling log_msg_ret() et al
Date: Wed, 19 Mar 2025 16:31:22 +0100	[thread overview]
Message-ID: <ad07a506-c7a4-43ed-93c1-24626974a2eb@cherry.de> (raw)
In-Reply-To: <CAFLszThmVOd2G2zSHy8mNHEQ=FW7c+KNTD_XLxiQgbMKM=AxXw@mail.gmail.com>

Hi Simon

On 3/19/25 4:03 PM, Simon Glass wrote:
> Hi Quentin,
> 
> On Wed, 19 Mar 2025 at 13:04, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>
>> Hi Simon,
>>
>> On 3/19/25 12:49 PM, Simon Glass wrote:
>>> Logging of function return-values is used very frequently in U-Boot now.
>>> Add a few helper macros to make it less verbose to use.
>>>
>>> It turns out that the log_ret() variants are not so useful, since it is
>>> not obviously where the error is coming from. So only the log_msg_ret()
>>> variants are worthy of these macros.
>>>
>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>> ---
>>>
>>>    include/log.h | 26 ++++++++++++++++++++++++++
>>>    1 file changed, 26 insertions(+)
>>>
>>> diff --git a/include/log.h b/include/log.h
>>> index 4f6d6a2c2cf..bdda7af570c 100644
>>> --- a/include/log.h
>>> +++ b/include/log.h
>>> @@ -380,6 +380,32 @@ void __assert_fail(const char *assertion, const char *file, unsigned int line,
>>>    #define log_msg_retz(_msg, _ret) ((void)(_msg), _ret)
>>>    #endif
>>>
>>> +/*
>>> + * LOGR() - helper macro for calling a function and logging error returns
>>> + *
>>> + * Logs if the function returns a negative value
>>> + *
>>> + * Usage:   LOGR("abc", my_function(...));
>>> + */
>>> +#define LOGR(_msg, _expr)    do {            \
>>> +     int _ret = _expr;                       \
>>> +     if (_ret < 0)                           \
>>> +             return log_msg_ret(_msg, _ret); \
>>> +     } while (0)
>>> +
>>> +/*
>>> + * LOGZ() - helper macro for calling a function and logging error returns
>>> + *
>>> + * Logs if the function returns a non-zero value
>>> + *
>>> + * Usage:   LOGZ("abc", my_function(...));
>>> + */
>>> +#define LOGZ(_msg, _expr)    do {            \
>>> +     int _ret = _expr;                       \
>>> +     if (_ret)                               \
>>> +             return log_msg_retz(_msg, _ret);        \
>>> +     } while (0)
>>> +
>>
>> Mmmm not sure this forced return call is a good idea, this would forbid
>> us from performing some unwinding for example.
> 
> Yes, it is really only for simple cases. Without the return, there
> isn't much value and you may as well not use this macro.
> 
>>
>> I don't really see how that is better than simply calling
>>
>> return log_msg_retz("abc", my_function());
> 
> That's not the intention. It actually replaces:
> 
> ret = my_function();
> if (ret)
>      return_log_msg_ret("abc", ret);
> 
> I use this a lot in my code. You can't always just return, since there
> may not be an error.
> 

I see, I read too fast again. Only return if it's an error.

>>
>> ?
>>
>> If we were to keep this, I would recommend to rename the macro and fix
>> the docstring because it does not only log if the function returns a
>> non-zero value. It does actually return.
>>
>> So something like
>>
>> LOGZ_AND_RETURN(_msg, _expr)
>>
>> maybe?
> 
> Sure, longer names are easier to learn, but then it is so long I doubt
> anyone would use it.
> 
> Perhaps LOG_RET() and LOG_RETZ() ? But they might get confused with
> log_ret() and log_retz(), which I am actually thinking of deleting.
> 
> I would like the shortest possible name to avoid spilling functions
> onto the next line all the time.
> 

It should be absolutely obvious from the macro name that this can in 
fact return because missing to unwind code is among the things 
developers typically easily miss already, so with this macro it'll be 
even easier to forget about undoing things.

I'm not sure this downside outweighs the benefits to be honest, but I 
also don't write a lot of code these days so /me shrugs

Cheers,
Quentin

  reply	other threads:[~2025-03-19 15:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-19 11:49 [PATCH] log: Add helpers for calling log_msg_ret() et al Simon Glass
2025-03-19 12:04 ` Quentin Schulz
2025-03-19 15:03   ` Simon Glass
2025-03-19 15:31     ` Quentin Schulz [this message]
2025-03-20  3:26       ` Simon Glass
2025-03-25 10:20         ` Quentin Schulz
2025-03-26 16:46           ` Simon Glass
2025-03-27 23:49             ` Tom Rini
2025-03-28 10:44               ` Simon Glass
2025-03-30 14:45                 ` Tom Rini
2025-04-01 15:48                   ` Simon Glass
2025-04-01 17:19                     ` Tom Rini
2025-04-03 17:57                       ` Simon Glass
2025-04-03 18:03                         ` Quentin Schulz
2025-04-03 18:05                           ` Simon Glass

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=ad07a506-c7a4-43ed-93c1-24626974a2eb@cherry.de \
    --to=quentin.schulz@cherry.de \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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