From: Ingo Molnar <mingo@elte.hu>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
Tejun Heo <tj@kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Pierre Tardy <tardyp@gmail.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, 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>
Subject: Re: PATCH [0/4] perf: clean-up of power events API
Date: Sat, 9 Oct 2010 08:28:36 +0200 [thread overview]
Message-ID: <20101009062836.GB5517@elte.hu> (raw)
In-Reply-To: <20101008134156.GA28724@Krystal>
* Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> * Arjan van de Ven (arjan@linux.intel.com) 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.
Changing an existing event in some non-append way is just sloppy and we
can do better.
Arjan, Pierre, does that sound OK to you?
Ingo
next prev parent reply other threads:[~2010-10-09 6:28 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
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 [this message]
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=20101009062836.GB5517@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.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=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