linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: tardyp@gmail.com, jean.pihet@newoldbits.com,
	acme@ghostprotocols.net, fweisbec@gmail.com,
	linux-perf-users@vger.kernel.org,
	linux-trace-users@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: Perf ABI versioning
Date: Mon, 24 Jan 2011 22:02:22 +0100	[thread overview]
Message-ID: <201101242202.23068.trenn@suse.de> (raw)
In-Reply-To: <20110124201225.GA14635@Krystal>

Hi,

Pierre may correct me if I am wrong, even pytimechart is not big,
I realized that I am not that good in python code reading...

On Monday 24 January 2011 21:12:25 Mathieu Desnoyers wrote:
> [ added Ingo, Steven, Thomas and Peter to CC list ]
> 
> I would agree, though, about the need for a version number on the way
> /sys/kernel/debug/tracing/events exports the binary event type and text-output
> formatting information: in order to cope with changes to the way this metadata
> is exported, we'd need such a versioning number.
pytimechart simply works on reading /sys/kernel/debug/trace
The big advantage is that you can copy things away to another machine.
I expect the same concept is with perf record and perf.data.
Theoretically you can attach perf.data to a bug report and everybody (considering
the userspace tool is new and maintained enough) can process the data.

I do not know the binary format of this file, but a version number would be
an easy way for userspace tools to figure out which events are supported
and in which format.

> But again, trying to version every tiny change to the fields per se won't scale
> with the development process given that we pull instrumentation changes from
> many different repository concurrently. The field layout information is there to
> deal with this problem, pytimechart should perhaps start using it.
I see that there are quite some changes, but why wouldn't it scale?
Even if every git commit automatically would increases the version, a userspace
tool would only pick out very specific versions it cares about:

if (version > 2000) {
    /* event x got introduced, try to catch it as well */
}
if (version < 3000) {
   /* event y did not have field z */
}
...

I would not introduce a major.minor just for the sake of it.

About Frederic's comment:
> Also, tracking the changes in the Documentation is going to be a
> nightmare. I suggest developers who want to dig into details of
> an ABI change to check the code or the format themselves.
If you want an ABI and userspace tools being able to cope with
it across kernel versions , there should be some documentation as well.
Let it only be one sentence containing the event to grep for. You can then
catch the details from the git commit id.

       Thomas

  reply	other threads:[~2011-01-24 21:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-24 16:04 Perf ABI versioning Thomas Renninger
2011-01-24 16:18 ` Thomas Renninger
2011-01-24 17:26 ` Pierre Tardy
2011-01-24 17:28 ` Jean Pihet
2011-01-24 20:05   ` Frederic Weisbecker
2011-01-24 20:12 ` Mathieu Desnoyers
2011-01-24 21:02   ` Thomas Renninger [this message]
2011-01-24 20:34 ` Frederic Weisbecker
2011-01-24 20:39   ` Peter Zijlstra
2011-01-24 20:40     ` Frederic Weisbecker
2011-01-24 21:28   ` Ingo Molnar
2011-01-24 21:49     ` Thomas Renninger
2011-01-24 21:57       ` Arnaldo Carvalho de Melo
2011-01-24 22:30         ` Thomas Renninger
2011-01-24 22:46           ` Frederic Weisbecker
2011-01-24 23:05             ` Arnaldo Carvalho de Melo
2011-01-24 21:59     ` Frederic Weisbecker

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=201101242202.23068.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=acme@ghostprotocols.net \
    --cc=fweisbec@gmail.com \
    --cc=jean.pihet@newoldbits.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-trace-users@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tardyp@gmail.com \
    --cc=tglx@linutronix.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;
as well as URLs for NNTP newsgroup(s).