From: Frederic Weisbecker <fweisbec@gmail.com>
To: Pierre Tardy <tardyp@gmail.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Thomas Renninger <trenn@suse.de>,
Jean Pihet <jean.pihet@newoldbits.com>,
linux-trace-users@vger.kernel.org,
linux-pm@lists.linux-foundation.org,
linux-perf-users@vger.kernel.org, mingo@elte.hu,
arjan@linux.intel.com, rjw@sisk.pl, linux-omap@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Kevin Hilman <khilman@deeprootsystems.com>,
Steven Rostedt <rostedt@goodmis.org>,
Frank Eigler <fche@redhat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Tejun Heo <tj@kernel.org>
Subject: Re: PATCH [0/4] perf: clean-up of power events API
Date: Thu, 7 Oct 2010 17:58:22 +0200 [thread overview]
Message-ID: <20101007155816.GA5351@nowhere> (raw)
In-Reply-To: <AANLkTikT4xsh7iCQDX8ksewJwC-BeFov=Ab7iYo+hDmO@mail.gmail.com>
On Thu, Oct 07, 2010 at 05:23:43PM +0200, Pierre Tardy wrote:
> On Thu, Oct 7, 2010 at 5:08 PM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> > [ Adding a few more CCs, since this discussion is about a tracepoint
> > userspace ABI policy, which is a topic of general interest. ]
>
> To add a little more comment, this is not the first time that
> tracepoints ABI changes. You can look at pytimechart sourcecode:
> http://gitorious.org/pytimechart/pytimechart/blobs/master/timechart/ftrace.py
>
> from 2.6.31 which is the first kernel I support,
>
> sched_switch: 'task %s:%d [%d] ==> %s:%d [%d]',
> changed to:
> sched_switch: 'prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s
> ==> next_comm=%s next_pid=%d next_prio=%d',
>
> workqueue_execution: 'thread=%s
> func=%s\\+%s/%s','thread','func','func_offset','func_size'),
> changed to:
> workqueue_execution: 'thread=%s func=%s','thread','func'),
>
Seems to be only formatting changes, but no field has been removed and
no tracepoint has been renamed, etc...
So these are no stable ABI changes because the formatting can be changed
anytime. We want that flexibility and it stands on top of the per event
"format" files.
Tools are not supposed to read ascii formatted traces from trace/trace_pipe
files. Instead they need to read binary traces from trace_pipe_raw files
and look at the format file to know how to format this.
This is why we have these format files: to let tools adapt with changes
like format change or fields added.
And we have a library in perf and trace-cmd that let you
- request a field value in a raw trace, by its name. So the field doesn't
need to have a stable offset in the trace.
- request ascii format info, so that if ascii format changes, the tool
adapt.
- record binary traces, much more leightweight for the writer (kernel)
and for the reader (user).
I did told you that it would be better you make PyTimeChart use the perf
scripting facilities, it handles all the above things + it would
avoid you to handle a lot of things.
Now it's up to you, but don't count on us to make the ascii formatting
a stable ABI.
> actually, over all the events pytimechart supports, only power traces
> are stable...
Now one problem is that we have really broken the workqueue tracepoints
in this release. I thought nobody was using them so we could
refactor this tracepoint subsystem, my bad.
workqueue_execution has become workqueue_execution_start and
workqueue_execution_end. workqueue_insertion is going to
suffer a similar split.
workqueue_creation and workqueue_destruction have disappear but
I can probably restore them, but for the rest, what should we do?
I really feel uncomfortable with this tracepoint/ABI problem....
Mathieu suggested we start a user library that could handle these
changes when they are really necessary.
Thoughts?
(Adding Tejun in Cc).
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-10-07 15:58 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 15:20 PATCH [0/4] perf: clean-up of power events API Jean Pihet
2010-10-04 15:20 ` [PATCH 1/4] perf: cleanup " Jean Pihet
2010-10-04 15:20 ` [PATCH 2/4] perf: add OMAP support for the new power events Jean Pihet
2010-10-04 19:45 ` Thomas Renninger
2010-10-04 15:21 ` [PATCH 3/4] perf: add calls to suspend trace point Jean Pihet
2010-10-04 22:52 ` Rafael J. Wysocki
2010-10-04 15:21 ` [PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space Jean Pihet
2010-10-04 16:10 ` Frank Ch. Eigler
2010-10-04 16:47 ` Jean Pihet
2010-10-06 21:34 ` PATCH [0/4] perf: clean-up of power events API Thomas Renninger
2010-10-07 15:08 ` Mathieu Desnoyers
2010-10-07 15:23 ` Pierre Tardy
2010-10-07 15:45 ` Steven Rostedt
2010-10-07 15:58 ` Frederic Weisbecker [this message]
2010-10-07 16:10 ` Pierre Tardy
2010-10-08 8:14 ` Tejun Heo
2010-10-08 8:38 ` Ingo Molnar
2010-10-08 13:17 ` Arjan van de Ven
2010-10-08 13:41 ` Mathieu Desnoyers
2010-10-08 16:22 ` Arjan van de Ven
2010-10-08 17:21 ` Steven Rostedt
2010-10-08 17:49 ` Frank Ch. Eigler
2010-10-08 18:11 ` Steven Rostedt
2010-10-08 17:32 ` Mathieu Desnoyers
2010-10-09 6:28 ` Ingo Molnar
2010-10-09 8:14 ` Pierre Tardy
2010-10-09 18:36 ` Linus Torvalds
2010-10-09 21:15 ` Steven Rostedt
2010-10-09 23:20 ` Linus Torvalds
2010-10-10 1:39 ` Steven Rostedt
2010-10-10 6:41 ` Peter Zijlstra
2010-10-10 15:11 ` Steven Rostedt
2010-10-18 12:15 ` Jean Pihet
2010-10-09 16:19 ` Arjan van de Ven
2010-10-09 21:34 ` Steven Rostedt
2010-10-10 12:19 ` Ingo Molnar
2010-10-19 11:31 ` Thomas Renninger
2010-10-19 11:45 ` Ingo Molnar
2010-10-19 11:47 ` Peter Zijlstra
2010-10-19 11:52 ` Ingo Molnar
2010-10-19 13:27 ` Arjan van de Ven
2010-10-19 13:50 ` Ingo Molnar
2010-10-19 13:52 ` Arjan van de Ven
2010-10-19 14:51 ` Ingo Molnar
2010-10-07 15:45 ` Jean Pihet
2010-10-07 15:49 ` Thomas Renninger
2010-10-07 15:56 ` Jean Pihet
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=20101007155816.GA5351@nowhere \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=fche@redhat.com \
--cc=jean.pihet@newoldbits.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linux-trace-users@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rjw@sisk.pl \
--cc=rostedt@goodmis.org \
--cc=tardyp@gmail.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=trenn@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox