From: "Ted Ts'o" <tytso@mit.edu>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>, Greg KH <gregkh@suse.de>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Arjan van de Ven <arjan@infradead.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lin Ming <ming.m.lin@intel.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC][PATCH 1/5] [PATCH 1/5] events: Add EVENT_FS the event filesystem
Date: Wed, 17 Nov 2010 13:42:31 -0500 [thread overview]
Message-ID: <20101117184231.GI3290@thunk.org> (raw)
In-Reply-To: <20101117150332.GA7603@elte.hu>
On Wed, Nov 17, 2010 at 04:03:32PM +0100, Ingo Molnar wrote:
>
> I think Arjan's complaints at the KS stemmed from prior sporadic
> declarations on lkml that there is no tracepoint ABI _at all_, and
> that powertop/latencytop could break anytime.
>
> But in reality i strongly disagree with such declarations, and
> tracepoint data that is used by PowerTop/timechart/latencytop or
> perf is and was an ABI, simple as that - and i've been enforcing
> that for two years. (We have so few good instrumentation tools that
> we _really_ dont want to break them.)
There was general consensus at the kernel summit that the tracepoints,
being deliberately in /sys/kernel/debug was unstable and today exposes
internal implementation details --- and that that people putting
different traceponts in Documentation/ABI/{testing,stable,unstable}
simply doesn't work.
Heck, I've recently had to make changes to tracepoints because
otherwise perf would fall over dead when it tripped over an ext4
tracepoint, due to its limitations dealing with what we could put into
TP_PRINTK(). Saying that tracepoints are stable ABI that must never
change, forever and ever, amen, is simply a non-starter.
> I simply dont see the 'problem' that is being solved here. We had a
> stable ABI and we didnt break sysprof or powertop/latencytop in the
> past and wont break it in the future either.
I think the general consensus is that we didn't have a stable ABI, and
the tension between what kernel developers need for debugging, which
of necessity is kernel version specific, and what gets exposed as a
stable ABI that tools can depend upon, is not one that can be
resolved.
Regards,
- Ted
next prev parent reply other threads:[~2010-11-17 18:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 0:53 [RFC][PATCH 0/5] tracing/events: stable tracepoints Steven Rostedt
2010-11-17 0:53 ` [RFC][PATCH 1/5] [PATCH 1/5] events: Add EVENT_FS the event filesystem Steven Rostedt
2010-11-17 3:32 ` Greg KH
2010-11-17 10:39 ` Ingo Molnar
2010-11-17 12:25 ` Steven Rostedt
2010-11-17 15:03 ` Ingo Molnar
2010-11-17 15:16 ` Peter Zijlstra
2010-11-17 15:16 ` Steven Rostedt
2010-11-17 15:35 ` Peter Zijlstra
2010-11-17 18:42 ` Ted Ts'o [this message]
2010-11-17 15:16 ` Peter Zijlstra
2010-11-23 21:29 ` Steven Rostedt
2010-11-17 17:46 ` Mathieu Desnoyers
2010-11-17 17:52 ` Steven Rostedt
2010-11-17 18:12 ` Mathieu Desnoyers
2010-11-18 9:42 ` Avi Kivity
2010-11-17 23:48 ` Ted Ts'o
2010-11-18 13:05 ` Mathieu Desnoyers
2010-11-17 12:16 ` Steven Rostedt
2010-11-17 0:53 ` [RFC][PATCH 2/5] [PATCH 2/5] tracing/events: Add code to (un)register stable events Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 3/5] [PATCH 3/5] tracing/events: Add infrastructure to show stable event formats Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 4/5] [PATCH 4/5] tracing/events: Add stable event sched_switch Steven Rostedt
2010-11-17 0:54 ` [RFC][PATCH 5/5] [PATCH 5/5] tracing/events: Add sched_migrate_task stable event Steven Rostedt
2010-11-17 20:14 ` [RFC][PATCH 0/5] tracing/events: stable tracepoints Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101117184231.GI3290@thunk.org \
--to=tytso@mit.edu \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=fweisbec@gmail.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.