On 10/8/2010 6:41 AM, Mathieu Desnoyers 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/ ? 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. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
