All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Schier <nsc@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Steven Rostedt <rostedt@kernel.org>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	linux-kbuild@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>,
	Arnd Bergmann <arnd@arndb.de>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH v9 2/4] tracing: Add a tracepoint verification check at build time
Date: Tue, 21 Oct 2025 23:21:17 +0200	[thread overview]
Message-ID: <aPf5TVismRLkQQOE@levanger> (raw)
In-Reply-To: <20251021154737.77377790@gandalf.local.home>

On Tue, Oct 21, 2025 at 03:47:37PM -0400, Steven Rostedt wrote:
> On Fri, 17 Oct 2025 22:15:20 +0200
> Nicolas Schier <nsc@kernel.org> wrote:
> 
> > > +# To check for unused tracepoints (tracepoints that are defined but never
> > > +# called), run with:
> > > +#
> > > +# make UT=1
> > > +#
> > > +# Each unused tracepoints can take up to 5KB of memory in the running kernel.
> > > +# It is best to remove any that are not used.
> > > +
> > > +ifeq ("$(origin UT)", "command line")
> > > +  WARN_ON_UNUSED_TRACEPOINTS := $(UT)
> > > +endif
> > > +
> > > +export WARN_ON_UNUSED_TRACEPOINTS  
> > 
> > Is there a special reason why you chose to introduce a new command-line
> > variable instead of extending KBUILD_EXTRA_WARN / W ?
> 
> Honestly, I didn't think about using KBUILD_EXTRA_WARN. I also want this
> option to go away after we remove the current unused tracepoints so that
> any new ones will always cause a warning.
> 
> The only reason not to make it always warn is because I don't want to add
> warnings for the existing code. I'm working on having outreachy projects to
> remove the currently unused tracepoints. Once that is done, then this
> option is going to go away and the build will always warn on unused
> tracepoints.
> 
> I thought it might be easier to remove it without any issues if it's a new
> command line that goes away in the future.
> 
> Looking at EXTRA_WARN, it appears to be for basic issues with the code and
> adds new C compiler warning flags. This isn't exactly the same.
> 
> If you think it makes sense to extend EXTRA_WARN, I can still go ahead and
> do that.

thanks for clarification!  For completeness: KBUILD_EXTRA_WARN is also
used for non-C related checks (cp. scripts/misc-check).
I somehow missed that UT= shall exist temporarily only - if this is
still the plan, I don't see a strong reason to put to much work into
integration in KBUILD_EXTRA_WARN.

Kind regards
Nicolas

  reply	other threads:[~2025-10-21 21:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 20:38 [PATCH v9 0/4] tracepoints: Add warnings for unused tracepoints and trace events Steven Rostedt
2025-10-15 20:38 ` [PATCH v9 1/4] sorttable: Move ELF parsing into scripts/elf-parse.[ch] Steven Rostedt
2025-10-15 20:38 ` [PATCH v9 2/4] tracing: Add a tracepoint verification check at build time Steven Rostedt
2025-10-15 23:12   ` Nathan Chancellor
2025-10-15 23:14     ` Steven Rostedt
2025-10-17 20:15   ` Nicolas Schier
2025-10-21 19:47     ` Steven Rostedt
2025-10-21 21:21       ` Nicolas Schier [this message]
2025-10-15 20:38 ` [PATCH v9 3/4] tracepoint: Do not warn for unused event that is exported Steven Rostedt
2025-10-15 20:38 ` [PATCH v9 4/4] tracing: Add warnings for unused tracepoints for modules Steven Rostedt
2025-10-15 23:19   ` Nathan Chancellor
2025-10-17 20:22     ` Nicolas Schier
2025-10-21 19:48       ` Steven Rostedt
2025-10-21 19:57     ` Steven Rostedt
2025-10-16 10:54   ` kernel test robot

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=aPf5TVismRLkQQOE@levanger \
    --to=nsc@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rostedt@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 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.