On Sunday 10 October 2010 14:19:28 Ingo Molnar wrote:
>
> * Arjan van de Ven <arjan@xxxxxxxxxxxxxxx> wrote:
>
...
> > 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 ......
Right, it's a frequency and a CPU that should get passed along with the
event. The X86/ACPI specific X-state data (even there unused and never will
get used) should vanish before ARM starts to make use of it.
The idle (power_start/power_end) state definition is worse...
> 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 -
Do you agree that this occurance happened now and these events
should get cleaned up before ARM and other archs make use of the broken
interface?
If not, discussing this further, is a big waste of time... and Jean
would have to try to adapt his ARM code on the broken ABI...
> and then
> we can deal with it intelligently, without breaking stuff unnecessarily.
Can we get this defined a bit clearer so that a patch can be created?
Compatibility can only be achieved by still firing the old events for
some kernel rounds.
I'll send some patches in a new thread with these people in CC.
It would be great to see a decision (in a way that a patch can be created)
how an event change can/should look like if there is urgent need.
Thanks,
Thomas
--
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
|