From: Crystal Wood <crwood@redhat.com>
To: Costa Shulyupin <costa.shul@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Tomas Glozar <tglozar@redhat.com>, John Kacur <jkacur@redhat.com>,
Jan Stancek <jstancek@redhat.com>,
Tiezhu Yang <yangtiezhu@loongson.cn>,
linux-trace-kernel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/5] tools/rtla: Add fatal() and replace error handling pattern
Date: Fri, 10 Oct 2025 12:50:17 -0500 [thread overview]
Message-ID: <c60f6d32159d02df6c2c98477d22705539909245.camel@redhat.com> (raw)
In-Reply-To: <CADDUTFwFerzjRTPp1F+Rw+_U2DoomAxyDonXudCwh9gyXSn=nw@mail.gmail.com>
On Fri, 2025-10-10 at 10:20 +0300, Costa Shulyupin wrote:
> On Thu, 9 Oct 2025 at 00:55, Crystal Wood <crwood@redhat.com> wrote:
> > Looks like there was existing inconsistency with newlines... maybe have
> > fatal() include the newline automatically to simplify callers slightly?
> > We're not going to print a continuation if we're exiting.
> >
> > Otherwise, for the whole series:
> > Reviewed-by: Crystal Wood <crwood@redhat.com>
>
> fatal() belongs to the same family as debug_msg() and err_msg().
> Historically, the prototype and usage of these functions is identical
> to printf().
> printk() was identical as well, but now it adds a missing end-of-line
> automatically.
> fatal(), along with debug_msg() and err_msg(),
> can be upgraded too, but they should be updated together for consistency.
Only fatal() has the "you're never going to get a chance to print a
continuation line so why would you ever not want a newline?" aspect.
And this would be consistent with panic() on the kernel side.
-Crystal
next prev parent reply other threads:[~2025-10-10 17:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 19:59 [PATCH v1 0/5] tools/rtla: Improve argument processing Costa Shulyupin
2025-10-08 19:59 ` [PATCH v1 1/5] tools/rtla: Add fatal() and replace error handling pattern Costa Shulyupin
2025-10-08 21:55 ` Crystal Wood
2025-10-10 7:20 ` Costa Shulyupin
2025-10-10 17:50 ` Crystal Wood [this message]
2025-10-08 19:59 ` [PATCH v1 2/5] tools/rtla: Replace timerlat_top_usage("...") with fatal("...") Costa Shulyupin
2025-10-08 19:59 ` [PATCH v1 3/5] tools/rtla: Replace timerlat_hist_usage("...") " Costa Shulyupin
2025-10-08 19:59 ` [PATCH v1 4/5] tools/rtla: Replace osnoise_hist_usage("...") " Costa Shulyupin
2025-10-08 19:59 ` [PATCH v1 5/5] tools/rtla: Replace osnoise_top_usage("...") " Costa Shulyupin
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=c60f6d32159d02df6c2c98477d22705539909245.camel@redhat.com \
--to=crwood@redhat.com \
--cc=costa.shul@redhat.com \
--cc=jkacur@redhat.com \
--cc=jstancek@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglozar@redhat.com \
--cc=yangtiezhu@loongson.cn \
/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).