Re: [RFC PATCH] dynamic debug - adding ring buffer storage support

From: Steven Rostedt
Date: Wed Dec 30 2009 - 20:44:26 EST


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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/