lkml.org 
[lkml]   [2010]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ANNOUNCE] New utility: 'trace'
From
Date
On Wed, 2010-11-17 at 09:30 +0100, Ingo Molnar wrote:
> * 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.

I don't see the point, the kernel shouldn't contain any trace_printk()s
to begin with..


\
 
 \ /
  Last update: 2010-11-17 12:39    [W:0.138 / U:0.024 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site