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

[Arjan van de Ven <arjan@linux.intel.com>]

  On 10/8/2010 6:41 AM, Mathieu Desnoyers 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/ ?

because that is not workable... at least nobody has shown to be able to 
make this work.
libraries (after compilation) live in /lib or /usr/lib (or lib64 I 
suppose).....
what mechanism ensures that a user who compiles his kernel gets a 
library compatible with that kernel in /usr/lib?
and can said library deal with older kernels too? And distro kernels?

> Why does everything *have* to be done in
> kernel-space
it doesn't. but the alternative must be workable.
>   Why are you so focused on making your application interact
> directly with kernel ABIs ?
>
> I'm being direct because there are trivial solutions to your problem that you
> are rejecting without due consideration. (and also I just had one coffee too
> many) ;-)

since you seem to think that dealing with such a library is trivial... 
how about you do it for one function even, to
show that the deployment/use-in-an-app is workable.
I'd be more than happy to use it if it's workable and the API is at 
least halfway sane.