Re: [PATCH v4 7/7] kernel.h: drop trace_printk.h
From: Jani Nikula <jani.nikula@linux.intel.com>
Date: 2026-01-05 09:30:04
Also in:
dri-devel, intel-gfx, linux-modules, lkml
From: Jani Nikula <jani.nikula@linux.intel.com>
Date: 2026-01-05 09:30:04
Also in:
dri-devel, intel-gfx, linux-modules, lkml
On Sat, 03 Jan 2026, Yury Norov [off-list ref] wrote:
On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:quoted
On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:quoted
On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:...quoted
I use trace_printk() all the time for kernel, particularly RCU development. One of the key usecases I have is dumping traces on panic (with panic on warn and stop tracing on warn enabled). This is extremely useful since I can add custom tracing and dump traces when rare conditions occur. I fixed several bugs with this technique. I also recommend keeping it convenient to use.Okay, you know C, please share your opinion what header is the best to hold the trace_printk.h to be included.What if we include it on Makefile level, similarly to how W=1 works? make D=1 // trace_printk() is available make D=0 // trace_printk() is not available make // trace_printk() is not available Where D stands for debugging. D=1 may be a default setting if you prefer, but the most important is that every compilation unit will have an access to debugging without polluting core headers.
You do realize this means recompiling everything when adding D=1 for debugging? BR, Jani. -- Jani Nikula, Intel