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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:

> * Arjan van de Ven (arjan@xxxxxxxxxxxxxxx) 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
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux