Re: [ANNOUNCE] New utility: 'trace'

[Peter Zijlstra]

On Wed, 2010-11-17 at 09:30 +0100, Ingo Molnar wrote:
> * Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
> 
> > On Tue, Nov 16, 2010 at 01:27:35PM -0800, Darren Hart wrote:
> > > On 11/16/2010 01:04 PM, Thomas Gleixner wrote:
> > >> We are pleased to announce a new tracing tool called 'trace'.
> > >>
> > >
> > > Hi Thomas, Ingo - Congrats and Thanks!
> > >
> > >> At this point we'd like to ask for feedback from other users of tracing tools,
> > >> which workflow components would you like to see in addition to what the 'trace'
> > >> tool is offering?
> > >>
> > >> Comments, bug reports, suggestions welcome,
> > >
> > > The first thing that comes to mind is trace_marker:
> > >
> > > echo "Test point A" > /sys/kernel/debug/tracing/trace_marker
> > >
> > > I've found this sort of markup to be useful using ftrace (with C  
> > > equivalents embedded in the test case). Is this supported?
> > 
> > 
> > No, the trace_marker file sends trace_printk events. And trace_printk
> > events needs to be converted to use the unified trace event interface
> > (ie: implement a struct ftrace_event_call).
> > 
> > This shouldn't be so hard, and there are several ways we could do this.
> > 
> > An idea is to reproduce the kernel file hierarchy in a "printk" event
> > subsystem, but this implies to allow subsystems nesting.
> > 
> > Imagine you have two trace_printk(), one in kernel/sched.c:117
> > and one in kernel/time/tick-sched.c:228
> > The result would be:
> > 
> > $ ls /sys/kernel/debug/tracing/events/printk
> > 
> > /sys/kernel/debug/tracing/events/printk:
> > enable  filter  kernel/
> > 
> > /sys/kernel/debug/tracing/events/printk/kernel:
> > enable  filter sched.c/ time/
> > 
> > /sys/kernel/debug/tracing/events/printk/kernel/sched.c:
> > enable  filter  117/
> > 
> > /sys/kernel/debug/tracing/events/printk/kernel/sched.c/117:
> > enable filter format id
> > 
> > /sys/kernel/debug/tracing/events/printk/kernel/time:
> > enable  filter tick-sched.c/
> > 
> > /sys/kernel/debug/tracing/events/printk/kernel/time/tick-sched.c:
> > enable  filter  228/
> > 
> > /sys/kernel/debug/tracing/events/printk/kernel/time/tick-sched.c/228:
> > enable filter format id
> > 
> > 
> > The format would be quite easy, and only one field for the whole string (strloc).
> > 
> > Not sure what to do with trace_marker. I just think we can add it as:
> > /sys/kernel/debug/tracing/events/printk/sys/kernel/debug/tracing/trace_marker
> > 
> > <:o)
> > 
> > 
> > But may be the whole idea is just fancy and nobody will care, [...]
> 
> I think it's an excellent idea, and it could also give us the framework to integrate 
> the dynamic_printk points.
> 
> > [...] and would just a simple single event in a printk subsystem, on which you can 
> > use a kind of virtual filter:
> > 
> > 	echo "path != kernel/whatever.c:226" > /sys/kernel/debug/tracing/events/printk/filter
> > 
> > would turn on every trace_printk() but the one in the given path.
> > 
> > Dunno, I like both ideas. I prefer the first one which looks to me more flexible: 
> > could be useful to list the user his trace_printks for example and implement an 
> > interface for him to quickly select the trace_printk he wants.
> 
> I prefer the first one too.
> 
> > For example I'm currently working with dozens of trace_printk() and I would be 
> > very happy to turn some of them off half of the time.
> 
> I guess we could try such a patch. If you send a prototype i'd be interested in 
> testing it out.

I don't see the point, the kernel shouldn't contain any trace_printk()s
to begin with..
--
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/