Re: [RFC][PATCH -tip 0/5 V2] tracing: kprobe-based event tracer

[Masami Hiramatsu <mhiramat@redhat.com>]

Andrew Morton wrote:
> On Fri, 20 Mar 2009 21:33:21 -0400 Masami Hiramatsu <mhiramat@redhat.com> wrote:
> 
>>   echo /debug/tracing/trace
> 
> Should be cat, I assume?

Ah, yes, thanks!

>> # tracer: nop
>> #
>> #           TASK-PID    CPU#    TIMESTAMP  FUNCTION
>> #              | |       |          |         |
>>            <...>-2376  [001]   262.389131: do_sys_open: @do_sys_open+0 0xffffff9c 0x98db83e 0x8880 0x0
>>            <...>-2376  [001]   262.391166: sys_open: <-do_sys_open+0 0x5 0xc06e8ebb
>>            <...>-2376  [001]   264.384876: do_sys_open: @do_sys_open+0 0xffffff9c 0x98db83e 0x8880 0x0
>>            <...>-2376  [001]   264.386880: sys_open: <-do_sys_open+0 0x5 0xc06e8ebb
>>            <...>-2084  [001]   265.380330: do_sys_open: @do_sys_open+0 0xffffff9c 0x804be3e 0x0 0x1b6
>>            <...>-2084  [001]   265.380399: sys_open: <-do_sys_open+0 0x3 0xc06e8ebb
> 
> Well...  this is cool and all that, but nowhere near as useful as kgdb! 
> Its main competition however will be plain old printk.

kgdb or other debugger might be able to use this tracer,
but this will provide just a low-level infrastructure.

> Do we really honestly think that this feature will be sufficiently useful
> to a sufficiently large number of kernel developers as to warrant
> inclusion?

No, I think it's just a starting point.

> Perhaps a bit more thought about some more complex use cases would help.
> 
> And given that the users of this (and other tracing features) are general
> kernel developers rather than tracing (or kprobes) developers, it would be
> nice to get some feedback and even testing/usage results from those people.
> ie: everyone else.

I hope so,

Thank you!

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com