Re: [PATCH v3 2/2] dynamic debug: allow printing to trace event

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 25 Aug 2020 08:53:25 -0700
Joe Perches <joe@perches.com> wrote:

> > The print buffer is statically allocated and managed using code borrowed
> > from __ftrace_trace_stack() and is limited to 256 bytes (four of these
> > are allocated per CPU to handle the various contexts); anything larger
> > will be truncated.  
> 
> There is an effort to avoid using trace_printk and the like
> so perhaps this feature should have the same compile time
> guard.

No, this is fine for being in a production kernel. Basically, these are
simply debug printk()s that can also be put into the trace buffer. The
key difference to trace_printk() is that they are an event that needs
to be enabled to write into the buffer.

The problem I'm avoiding with not letting people add trace_printk() is
that trace_printk() should be used when a developer is trying to debug
some code. The *only* trace_printk()s should be the ones that developer
adds (because it only shows what they want to find).

trace_printk()s are enabled by default, and they have a special
switch to disable. But it is an all or nothing switch. They either
enable all of them, or disable all of them. No in between.

Now if we allow trace_printk()s to be scattered through the kernel,
when someone wants to use trace_printk() for their own debugging, and
it is turned on, now the trace buffer is filled with a bunch of "noise"
from all these other trace_printk()s that are scattered around, and the
trace_printk()s that the poor developer added are lost among the sea of
other trace_printk()s, making their trace_printk()s useless.

That is the reason I try hard not letting trace_printk() enter into the
kernel.

-- Steve