|| ||Steven Rostedt <rostedt-AT-goodmis.org> |
|| ||Arjan van de Ven <arjan-AT-linux.intel.com> |
|| ||Re: [PATCH 1/2] PERF(kernel): Cleanup power events |
|| ||Fri, 01 Oct 2010 18:08:35 -0400|
|| ||Thomas Renninger <trenn-AT-suse.de>,
linux-perf-users-AT-vger.kernel.org, mingo-AT-elte.hu, rjw-AT-sisk.pl,
jean.pihet-AT-newoldbits.com, Peter Zijlstra <peterz-AT-infradead.org>,
Kevin Hilman <khilman-AT-deeprootsystems.com>,
Frank Eigler <fche-AT-redhat.com>|
|| ||Article, Thread
On Fri, 2010-10-01 at 14:47 -0700, Arjan van de Ven wrote:
> On 10/1/2010 2:44 PM, Steven Rostedt wrote:
> > What ABI is broken? Trace points have not been declared an ABI. They
> > expose too much of the internals of the system to be considered one. Any
> > tool that can not cope with a tracepoint change is fundamentally broken.
> what you are saying that any tool using tracepoints is fundamentally
I did not say that. I said a tool that can not cope with a change is.
There's a difference.
> these tracepoints are used to get information for tools that do power
> analysis (like powertop).
> while the absence of these named tracepoints does not cause a crash;
> these tools have no longer
> any useful function left at that point.
What about adding a config file or script to the tool that can map
tracepoints, and how to read them based on the availability of a
Once we start saying that a tracepoint is a fixed abi, we just stopped
innovation of the kernel. Tracepoints are too intrusive to guarantee
their stability. Tools that need to get information from a tracepoint
should either be bound to a given kernel, or have a easy way to update
the tool (config file or script) that can cope with a change.
When the user runs the tool, it would examine what tracepoints are
available and if it does not find anything it could use, it could output
to the user, a message like "Can not find necessary tracepoints. Either
the running kernel does not have them configured, or you need to update
your config file. Please check for new updates at <your url here>".
Tracepoints took a long time to get into the kernel namely because
people were worried that we were exposing events that could never
change. When we proposed these events, it was always presented as "these
may change without notice. Cope with it".
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)