lkml.org 
[lkml]   [2009]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2009-03-21 12:25    [W:0.044 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site