[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251229111748.3ba66311@gandalf.local.home>
Date: Mon, 29 Dec 2025 11:17:48 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: "Yury Norov (NVIDIA)" <yury.norov@...il.com>, Masami Hiramatsu
<mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Christophe Leroy
<chleroy@...nel.org>, Randy Dunlap <rdunlap@...radead.org>, Ingo Molnar
<mingo@...nel.org>, Jani Nikula <jani.nikula@...ux.intel.com>, Joonas
Lahtinen <joonas.lahtinen@...ux.intel.com>, David Laight
<david.laight@...box.com>, Petr Pavlu <petr.pavlu@...e.com>, Andi Shyti
<andi.shyti@...nel.org>, Rodrigo Vivi <rodrigo.vivi@...el.com>, Tvrtko
Ursulin <tursulin@...ulin.net>, Daniel Gomez <da.gomez@...nel.org>, Greg
Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki"
<rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>,
linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-modules@...r.kernel.org,
linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
On Sun, 28 Dec 2025 13:31:50 -0800
Andrew Morton <akpm@...ux-foundation.org> wrote:
> > trace_printk() should be as available to the kernel as printk() is.
>
> um, why? trace_printk is used 1% as often as is printk. Seems
> reasonable to include a header file to access such a rarely-used(!) and
> specialized thing?
It will waste a lot of kernel developers time. Go to conferences and talk
with developers. trace_printk() is now one of the most common ways to debug
your code. Having to add "#include <linux/trace_printk.h>" in every file
that you use trace_printk() (and after your build fails because you forgot
to include that file **WILL** slow down kernel debugging for hundreds of
developers! It *is* used more than printk() for debugging today. Because
it's fast and can be used in any context (NMI, interrupt handlers, etc).
But sure, if you want to save the few minutes that is added to "make
allyesconfig" by sacrificing minutes of kernel developer's time. Go ahead
and make this change.
I don't know how much you debug and develop today, but lots of people I
talk to at conferences thank me for trace_printk() because it makes
debugging their code so much easier.
The "shotgun" approach is very common. That is, you add:
trace_printk("%s:%d\n", __func__, __LINE__);
all over your code to find out where things are going wrong. With the
persistent ring buffer, you can even extract that information after a
crash and reboot.
There's very few instances of it in the kernel because I made it that way.
If you add a trace_printk() in the kernel, you get the banner:
**********************************************************
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use. **
** **
** If you see this message and you are not debugging **
** the kernel, report this immediately to your vendor! **
** **
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
**********************************************************
in your dmesg.
I've been recommending people that if you find a "trace_printk()" useful,
you should convert it into a normal TRACE_EVENT() for submission. Which
many developers have done.
Yes, it's not in your kernel, but it is in several other people's kernels
as they develop it. And adding a requirement that they need to include a
header file for every place they add it (and then have to remember to
remove that header file when they are done debugging) is going to waste
more precious time that kernel developers don't have much of.
-- Steve
Powered by blists - more mailing lists