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


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux