mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@kernel.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-kernel@vger.kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [for-next][PATCH 0/3] tracing: Trigger a warning on build if a tracepoint is defined but unused
Date: Thu, 28 Aug 2025 17:13:46 -0400	[thread overview]
Message-ID: <20250828171346.21642d91@batman.local.home> (raw)
In-Reply-To: <20250829070224.503ddc8a@canb.auug.org.au>

On Fri, 29 Aug 2025 07:02:24 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> [Pretending to be Linus :-)]
> 
> So, have you fixed up the 178 new warnings you know about?  I cannot
> possibly do that, or even notify the offenders.  Please do that before
> adding this code to linux-next.
> 
> But, really, these known warnings can just make it so much harder to
> notice new ones.

Then this won't get in. I simply don't have the time to fix the current
ones. I did 20 or so, and that took me all day (which I did on a
holiday). And this work is something I'm already doing on my own time,
as my employer has other priorities for me to work on.

But it is something that is needed as there's currently nothing that
tells you that you have a tracepoint not used, and the are growing in
numbers and wasting more memory.

There is an option that needs to be enabled. Now this will get enabled
with allmodconfig or allyesconfig, but scripts that do tests could
disable it. Or I can make it a tri op that doesn't get set by one of
those (but randconfig may set it).

As for fixing the warnings, it really belongs to whoever added the
tracepoint (git blame will give you that). And would be a great project
for an intern (which I don't have any).

-- Steve

  reply	other threads:[~2025-08-28 21:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-28 18:27 Steven Rostedt
2025-08-28 18:27 ` [for-next][PATCH 1/3] sorttable: Move ELF parsing into scripts/elf-parse.[ch] Steven Rostedt
2025-08-28 19:03   ` Nicolas Schier
2025-08-28 19:36     ` Steven Rostedt
2025-08-28 18:27 ` [for-next][PATCH 2/3] tracing: Add a tracepoint verification check at build time Steven Rostedt
2025-08-28 18:27 ` [for-next][PATCH 3/3] tracepoint: Do not warn for unused event that is exported Steven Rostedt
2025-08-28 21:02 ` [for-next][PATCH 0/3] tracing: Trigger a warning on build if a tracepoint is defined but unused Stephen Rothwell
2025-08-28 21:13   ` Steven Rostedt [this message]
2025-08-29 12:10   ` Steven Rostedt

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=20250828171346.21642d91@batman.local.home \
    --to=rostedt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®