Messages in this thread | | | Date | Sat, 21 Mar 2009 04:13:16 -0700 | From | Andrew Morton <> | Subject | Re: [RFC][PATCH -tip 0/5 V2] tracing: kprobe-based event tracer |
| |
On Fri, 20 Mar 2009 21:33:21 -0400 Masami Hiramatsu <mhiramat@redhat.com> wrote:
> echo /debug/tracing/trace
Should be cat, I assume?
> # 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.
Do we really honestly think that this feature will be sufficiently useful to a sufficiently large number of kernel developers as to warrant inclusion?
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.
| |