lkml.org 
[lkml]   [2020]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] dynamic debug: allow printing to trace event
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

\
 
 \ /
  Last update: 2020-07-22 13:38    [W:0.183 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site