* Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> 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/ ? Why does everything *have* > to be done in kernel-space ? Why are you so focused on making your > application interact directly with kernel ABIs ? The thing is, Arjan is 100% right that a library for this is not a 'solution', it's an unnecessary complication. What i suggested in my mail was to _keep existing events_. I.e. do not break powertop. We are 100% happy that we _have_ such apps, and we should do reasonable things to not break them. If we need to change events, we can add a new event. The old events will lose their relevance without us having to do much - and without us having to break powertop, pytimechart, etc. We can even have periods of overlap when both events are available - to give instrumentation apps time to learn the new events. I.e. it's not an ABI in the classic sense - we do not (because we cannot) guarantee the infinite availability of these events. But we can guarantee that the fields do not change in some stupid, avoidable way. Changing an existing event in some non-append way is just sloppy and we can do better. Arjan, Pierre, does that sound OK to you? Ingo -- 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
|