Hi,
On Mon, Oct 4, 2010 at 6:10 PM, Frank Ch. Eigler <fche@xxxxxxxxxx> wrote:
> Hi -
>
>> Provide a CONFIG_DEPRECATED_POWER_EVENT_TRACING option in order
>> to provide backward compatibility with the user space tracing tools.
>
> This is clever:
>
>> +/* Map new events trace points calls to old ones */
>> +#define trace_processor_idle(state, cpu_id) \
>> + do { \
>> + if (state != 0) \
>> + trace_power_start(POWER_CSTATE, state, cpu_id); \
>> + else \
>> + trace_power_end(cpu_id); \
>> + } while (0)
>
> but with this code, are the new tracepoints firing at all? In other
> words, does this backward-compatibility config option effectively
> disable the newer ones? If so, this is probably avoidable.
Yes the events are fired. In fact with the CONFIG option defined the
trace_processor_* trace points are not defined, only the macro remaps
them (at compile time) to the old ones.
> Instead of redirecting the new tracepoint calls to these macros, an
> alternative may intercept (un)registration for the old tracepoint
> names, and map them to (un)registration of the real tracepoints. See
> how syscall tracepoints map to a special (un)registration callback in
> include/trace/events/syscalls.h (syscall_*regfunc). Instead of
> setting a TIF flag, the new functions can call
> register_processor_idle() et al., and their respective callbacks can
> call the backward-compatibility tracepoints.
>
> The starting point would be to recast the power_start, power_end,
> power_frequency tracepoints via TRACE_EVENT_FN() instead of
> TRACE_EVENT().
That could be done but it is not easy to do. In fact the power.h is
included and parsed multiple times in order to generate the trace
points prototype function _and_ the trace generation code. Please
check 'include/trace/ftrace.h' which is really smart but rather
complicated.
I am aiming at simple to read and maintainable code. Furthermore the
code is going to be removed soon or later.
Thanks for the suggestion!
>
> - FChE
>
Jean
--
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
