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.
--
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
