On 10/19/2010 6:50 AM, Ingo Molnar wrote:
* Arjan van de Ven<[email protected]> wrote:
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstra<[email protected]> wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renninger<[email protected]> wrote:
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...
The discussion seems to have died down somewhat. Please re-send to lkml the
latest
patches you have to remind everyone of the latest state of things - the merge
window
is getting near.
My only compatibility/ABI point is basically that it shouldnt break _existing_
tracepoints (and users thereof). If your latest bits meet that then it ought to
be a
good first step. You are free to (and encouraged to) introduce more complete
sets of
events.
Can we deprecate and eventually remove the old ones, or will we be forever
obliged
to carry the old ones too?
We most definitely want to deprecate and remove the old ones - but we want to
give
instrumentation software some migration time for that.
Jean, Arjan, what would be a feasible and practical deprecation period for
that? One
kernel cycle?
more like a year
for some time software needs to support both, especially if popular distros
stick
to an older kernel like *cough* RHEL6
Sure, you can support both. But as long as support for the _new_ events is
included
in PowerTop there's no need to keep the duality upstream. Running ancient
PowerTop
on fresh kernels is not common.
An old RHEL kernel will still keep on working as you can keep support for old
events
in PowerTop as long as you wish to.
The new kernel also wont 'overwrite' old events with new definitions in the
future,
so PowerTop will keep working for as long as you want to support older kernels.
Does that sound good?
this does not scale much long term, eg this only works if this is only
done once, and these points are stable afterwards.
otherwise we get 25 of those different "workarounds for kernel ABI
breakage" into all different projects, and it becomes
untestable for all the poor software writers...
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
