Re: [ANNOUNCE] New utility: 'trace'

[Ingo Molnar <mingo@elte.hu>]

* Frederic Weisbecker <fweisbec@gmail.com> 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.

Thanks,

	Ingo