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 ...... _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
