Messages in this thread | | | Date | Tue, 16 Nov 2010 23:17:28 +0100 | From | Frederic Weisbecker <> | Subject | Re: [ANNOUNCE] New utility: 'trace' |
| |
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, 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.
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.
| |