* Arjan van de Ven (arjan@xxxxxxxxxxxxxxx) wrote: > 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? I don't think the perf tools/ do it right at the moment, but here is my proposal: Currently, we need to do make install from the tools/ directory. Since kernel developers are lazy, I would propose a CONFIG_INSTALL_TOOLS default N config option that would let make install from the root of the kernel tree install the tools too. (looking at my inbox..) As Steven just beat me to it, see his lib versioning proposal. ;) The library would present an API to the application that would let apps consume specific events of interest. Translation of fixed event names/fields into the current kernel version tracepoint names/fields would be performed by the lib, and the library would also deal with reading the perf events through the perf ABI and would act as a middle-man to make sure they are always perceived by the application in the same way. > and can said library deal with older kernels too? And distro kernels? Steven's proposal should work. > >> 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. I currently have a lot on my plate with trace format and ring buffer, but if anyone is interested in trying to implement this, I can look at it and provide feedback/hints. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- 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
