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 > broken... 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 tracepoint? 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". -- Steve _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
