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-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|