* Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote: > On 10/8/2010 11:28 PM, Ingo Molnar wrote: > >* 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. > > also I have to say that some events are more likely to change than others > > "function foo in the kernel called" is more likely to change than "the > processor went to THIS frequency". The concept of CPU frequencies has > been with us fora long time and is going to be there for a long time > as well ...... Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - and then we can deal with it intelligently, without breaking stuff unnecessarily. Thanks, 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
|