Re: PATCH [0/4] perf: clean-up of power events API

Ingo Molnar
2010-10-09T06:28:36Z

* Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> * Arjan van de Ven (arjan@linux.intel.com) wrote:
> > On 10/8/2010 1:38 AM, Ingo Molnar wrote:
> >>
> >> The fundamental thing about tracing/instrumentation is that there
> >> are no deep ABI needs: it's all about analyzing development kernels
> >> (and a few select versions that get the enterprise treatment) but
> >> otherwise the half-life of this kind of information is very short.
> >>
> >> So we dont want to tie ourselves down with excessive ABIs.
> >
> > ok I'll start working on a second mechanism then to export
> > information that applications need ;-( it'll look a lot like tracing
> > I suppose ;-(
>
> What's wrong with doing the compatibility layer in a LGPL library
> shipped with the kernel tree under tools/ ? Why does everything *have*
> to be done in kernel-space ? Why are you so focused on making your
> application interact directly with kernel ABIs ?

The thing is, Arjan is 100% right that a library for this is not a
'solution', it's an unnecessary complication.

What i suggested in my mail was to _keep existing events_. I.e. do not
break powertop. We are 100% happy that we _have_ such apps, and we
should do reasonable things to not break them.

If we need to change events, we can add a new event. The old events will
lose their relevance without us having to do much - and without us
having to break powertop, pytimechart, etc. We can even have periods of
overlap when both events are available - to give instrumentation apps
time to learn the new events.

I.e. it's not an ABI in the classic sense - we do not (because we
cannot) guarantee the infinite availability of these events. But we can
guarantee that the fields do not change in some stupid, avoidable way.

Changing an existing event in some non-append way is just sloppy and we
can do better.

Arjan, Pierre, does that sound OK to you?

Ingo