Messages in this thread | | | Date | Wed, 23 Jul 2014 14:53:19 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH] ftrace: kill global_start_up |
| |
On Wed, 23 Jul 2014 20:29:11 +0200 Oleg Nesterov <oleg@redhat.com> wrote:
> > Nevermind, seems that Namhyung Kim beat you to it (and it's already in > > my for-next branch). > > > > http://lkml.kernel.org/r/1402584972-17824-1-git-send-email-namhyung@kernel.org > > Thanks for your report Steven, I updated my ~/people-i-hate file.
Is that for me or Namhyung? Silly question, it has to be for Namhyung, as I'm sure I'm one of the first people already in that list.
> > > This motivated me to try to find something else unused. And it seems that > almost all code in kernel/trace/trace_sched_switch.c is dead? Hmm, and
sched_switch? Move along, nothing to see here...
OK, there was a time we had a bunch of "tracers" (those things in the available_tracers file). And since events and perf came along, there was a push to remove them all. We never got rid of function, function_graph, mmiotrace and the latency tracers as they are quite different from events (function is close, but they need special care).
One of the casualties to that tracer purge was the sched_switch tracer. But it wasn't such a simple removal, as that code was in charge of the trace_find_cmdline() logic. Well, to get people away from using it, we removed it from the "available_tracers" file, but kept most of the code as clean up for another day.
As with most things on a TODO list, they get pushed down to the bottom, crushed by the many things above it, and finally swept under the rug until some nosy developer decides to take a peek under that carpet and point to the maintainer of said code with his white glove on and the smudge at the end of his finger and say "WHAT'S THIS!".
Well, here's a broom and dustpan, have at it!
> probably even event_context_switch... I'll recheck and send the patch. > > But is there any documentation about /sys/kernel/debug/tracing/events/ftrace/* > files ?
No, they are mostly internal, and only there for the format files for things like trace-cmd and perf to be able to parse it.
> > OK, as I just figured out ftrace/function is special, it is visible to > perf and thus "record ftrace:function" should work. > > But what a user can do with other files? You obviously can't enable, say, > ftrace/bputs, if I understand correctly this is for trace_puts(). >
Yeah, as trace_printk() can turn into a trace_puts() we still want those to be read by trace-cmd. To do that, the formats for those files are exported.
See kernel/trace/trace_export.c and trace_entries.h
> Confused...
Aren't we all?
-- Steve
| |