On Sat, Oct 9, 2010 at 8:36 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy <tardyp@xxxxxxxxx> wrote:
>> On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
>>>
>>
>>> The thing is, Arjan is 100% right that a library for this is not a
>>> 'solution', it's an unnecessary complication.
>> Yes. sounds like overengineering.
>
> I also want to remind people that backwards compatibility should
> always absolutely be the #1 priority. Using libraries to "hide"
> differences is a totally moronic thing to do, because if you can do a
> compatibility library with good interfaces, then damn it, the kernel
> interface should already _be_ that good interface.
Agree on that. The idea is to have the kernel interfaces cleaned up
and so have better user space apps in the end.
> And no, even if you interact purely with open source programs, the
> backwards compatibility requirement doesn't go away. It's a damn pain
> in the ass to have to recompile, and it means that you have a much
> harder time mixing and matching, and just updating the kernel on top
> of a standard distribution.
>
> So changing kernel interfaces that get exported to user space is
> always a disaster. Anybody who _designs_ for that kind of disaster
> shouldn't be participating in kernel development, because they've
> shown themselves to be unable to understand the pain and suffering.
>
> Yes, we do it. Sometimes we change interfaces because not changing
> them is too damn painful. But it should absolutely not be the design
> model.
So what is the best way to have the power tracing events elegantly cleaned up?
The proposed patch 4/4 [1] introduces a new Kconfig option
CONFIG_DEPRECATED_POWER_EVENT_TRACING which allows to select to map
the trace points to the old _OR_ to the new events API, only for the
already existing events. This gives some time for the adaptation of
the user space apps.
I understand this could require a kernel re-compilation in order to
use the old events API but I really want to avoid to duplicate the
trace points in the code to instrument, e.g.:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 199dcb9..013c274 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -354,5 +354,7 @@ void cpufreq_notify_transition(struct
cpufreq_freqs *freqs, unsigned int state)
adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
dprintk("FREQ: %lu - CPU: %lu", (unsigned long)freqs->new,
(unsigned long)freqs->cpu);
trace_power_frequency(POWER_PSTATE, freqs->new, freqs->cpu);
+ trace_power_switch_state(POWER_PSTATE, freqs->new, freqs->cpu,
+ smp_processor_id());
The proposed patch only changes the power tracing events API
definition files, not the code to instrument.
I am OK to re-spin the patches, only if a compromise is agreed on.
As said before the kernel Documentation and pytimechart user space
tools patches will be provided as well.
>
> Linus
>
Thanks,
Jean
[1] http://marc.info/?l=linux-omap&m=128620575900689&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
