On Mon, Jan 05, 2026 at 11:29:51AM +0200, Jani Nikula wrote:
> On Sat, 03 Jan 2026, Yury Norov <[email protected]> wrote:
> > On Sat, Jan 03, 2026 at 02:57:58PM +0200, Andy Shevchenko wrote:
> >> On Fri, Jan 02, 2026 at 07:50:59PM -0500, Joel Fernandes wrote:
> >> > On Mon, Dec 29, 2025 at 11:17:48AM -0500, Steven Rostedt wrote:
> >>
> >> ...
> >>
> >> > 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?
Yes sir I do.
It would be as simple (or hard) as building another arch:
make O=../build/linux-arm64
make O=../build/linux-x86_64
make D=1 W=1 O=../build/linux-x86_64-dev
If you're both developer and CI engineer in your company, you're likely
already doing something like that. If you're CI-only, there're no
changes for you. If you're a developer - yeah, you'd have to learn a
new flag.
The real problem of course is the status inflation. The fact that
defconfig enables CONFIG_EXPERT and CONFIG_DEBUG_KERNEL implies that
every random person who is able to do:
git clone && make && sudo make install
now assumed an expert kernel user and active developer. It is not
correct, and it leads to bloating kernel with dev-only features.
What we discuss here is a new marker for those real experts and
developers, I think. (In an hope that it will inflate not very fast.)
Thanks,
Yury
