Messages in this thread | | | Date | Wed, 22 Jul 2020 20:37:10 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [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
| |