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

[Sergey Senozhatsky <sergey.senozhatsky@gmail.com>]

On (20/07/21 17:30), Steven Rostedt wrote:
> On Tue, 21 Jul 2020 16:11:05 +0200
> Vincent Whitchurch <vincent.whitchurch@axis.com> wrote:
> 
> > When debugging device drivers, I've found it very useful to be able to
> > redirect existing pr_debug()/dev_dbg() prints to the trace buffer
> > instead of dmesg.  Among the many advantages of the trace buffer is that
> > it can be dynamically resized, allows these prints to combined with
> > other trace events, and doesn't fill up system logs.
> > 
> > Since dynamic debug already has hooks in these call sites, getting these
> > prints into the ftrace buffer is straightforward if we have dynamic
> > debug do it.
> > 
> > Add an "x" flag to make the dynamic debug call site print to a new
> > printk:dynamic trace event.  The trace event can be emitted instead of
> > or in addition to the printk().  The print buffer is placed on the stack
> > and is limited to a somewhat arbitrarily chosen 256 bytes; anything
> > larger will be truncated.
> 
> Is it safe to have a 256 byte string on the stack? That's quite a bit.
> How deep is the stack when this is called?
> 
> You could run vsnprintf() with a zero length to get the size, and then
> just allocate that from the ring buffer. How critical is the performance?

Hmm.
Can trace event contain a fixed size buffer or a dynamic array; then
we'll pass fmt and va_list to trace event so it can vscnprintf() into
its buffer in assign function?

	-ss