lkml.org 
[lkml]   [2009]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] dynamic debug - adding ring buffer storage support
From
Date
On Wed, 2009-12-30 at 23:50 +0100, Frederic Weisbecker wrote:

> That said, I sometimes dream about one event per printk.
>
> Having, say:
>
> /debug/tracing/events/printk/
> |
> ---- kernel/
> | |
> | ------- time/
> | | |
> | | ---- clocksource.c
> | | |
> | | --- clocksource_unstable:218/
> | | | |
> | | | ---- format
> | | | |
> | | | ---- filter
> | | | |
> | | | ---- enable
> | | --- [...]
> | ------- [...]
> |
> ---- drivers/
> | |
> | ---- [...]
> |
> ---- [...]
>
>
> That would give a total control over every printk, trace_printk, etc...
>
> Too bad that would bloat the memory.
> Well, that could be wrapped in a single, wildly implemented (understand:
> not using TRACE_EVENT macro) trace event, something able to walk through
> every calls of printk, trace_printk, early_printk, etc... and imitate
> a per printk event granularity.
>
> But still it needs to be useful...


I think we can do the above without bloating memory. Yes we would not
need the TRACE_EVENT macro for this. The TRACE_EVENT macro is just for
generic tracing, but we could easily come up with something specific for
the printk's that will not bloat the kernel as much.

When I get some time, I may try to play with this idea.

-- Steve





\
 
 \ /
  Last update: 2009-12-31 02:47    [W:0.046 / U:1.924 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site