Messages in this thread | | | Subject | Re: [RFC PATCH] dynamic debug - adding ring buffer storage support | From | Steven Rostedt <> | Date | Wed, 30 Dec 2009 20:44:17 -0500 |
| |
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
| |