[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081125153653.GA21001@elte.hu>
Date: Tue, 25 Nov 2008 16:36:53 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Frédéric Weisbecker <fweisbec@...il.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Human readable output for function return tracer
* Frédéric Weisbecker <fweisbec@...il.com> wrote:
> I made a patch last evening and I almost finished implementing the
> desired output.
>
> But while I went through, I was adding some more keywords with other
> "return-function-tracing" semantics, plus the risk of confusion
> resulting from the entry-on-function-for-return-tracing keywords....
>
> I planned to change all the keywords according to a new name for
> this tracer just after this patch. But I can't seriously submit such
> a mess, even with a second patch that fixes the keywords....
>
> I would like to change the name of the tracer and its keywords
> before sending the output changes.
> Do you agree with "full function tracer" (since we hook now on the
> two sides)?
"full function tracer" sounds a bit funny and quirky. How about
"function call tracer"? Versus the "function tracer" or "function
entry tracer" which is the lighter variant - both in name and in
overhead. So we'd have:
# cat /debug/tracing/available_tracers
mmiotrace wakeup irqsoff function function-call sysprof sched_switch initcall nop
note how intuitive it is: "function-call" is 'more' than just the
plain function-tracer. It also expresses its main property: it traces
the full call, entry and exit and return code as well.
Hm?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists