Message-ID: <20120423144743.GB29985@somewhere>
Date:	Mon, 23 Apr 2012 16:47:45 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>,
	Namhyung Kim <namhyung.kim@....com>,
	Jiri Olsa <jolsa@...hat.com>
Cc:	Arun Sharma <asharma@...com>, Michael Rubin <mrubin@...gle.com>,
	David Sharp <dhsharp@...gle.com>,
	Vaibhav Nagarnaik <vnagarnaik@...gle.com>,
	Julia Lawall <julia@...u.dk>, Tom Zanussi <tzanussi@...il.com>
Subject: Our failure on tracing tools unification (Was: Re: [RFC][PATCH
 00/15] tools: Unify perf and trace-cmd trace event format parsing v2)

On Fri, Apr 06, 2012 at 12:47:51AM +0200, Frederic Weisbecker wrote:
> 
> Hi,
> 
> So this is a new iteration of the libtracevent library, basically a
> rebase of https://lkml.org/lkml/2011/8/5/299 against latest progresses
> (latest tip/perf/core + tip/perf/urgent).
> 
> This library unifies the trace events parsing code between perf and
> trace-cmd. I initially took this parsing code from trace-cmd to make
> perf able to display trace-events and play with their contents.
> 
> But there is a continuous drift between perf and trace-cmd trace event
> parsing code since then because the fork I did and the original code in
> trace-cmd have never merged into a common entity. As a result, perf
> stays backward because we haven't ported all the progresses that
> trace-cmd did in this area.
> 
> Considering the reactions after the last attempt, it appears the
> unification of this code is uncontroversial. What seem to cause 
> problems is how we do it:
> 
> - as an internal library inside perf, where other tools can hook
> - as a self-contained library in tools/lib, independant from perf
> 
> The argument for the first solution was that trace events format
> is not mature enough to be available for any tool and thus it's too
> early to release a library that would engrave into the stone an
> interface to it, preventing the events format from evolving in the
> future.
> 
> However users of trace events are there already and they all use
> their own parsing. They sometimes wrongly rely on the stability of a
> whole event layout or its ascii structure. The lack of a common and
> independant library is eventually what prevents us from doing progresses
> or make evolutions on trace events.
> 
> So I think we really need to restart the debate. We strongly need to make
> progresses in this area so I'm posting this iteration in the hope we
> can move forward. With the coming of uprobes, there are some chances
> that our tracing becomes more important in the future. Let's join
> our efforts.

I'm trying to summarize some conversations that I got outside the mailing
list (and I truly regret because it should have been debated publicly).

Ingo doesn't seem to want this library outside perf in order to avoid
the fragmentation of the efforts on tracing tools.

We indeed want to unify our tools, like merging trace-cmd into perf.
And after talking with Steve about that, he told me he wants to have
both tools unified as well. But he wants to keep libparseevent as
a generic standalone library.

Indeed, it makes it possible for those who want to use trace events
on their own tools to do it properly. I believe powertop fits into
this scheme. Trace events are a generally useful feature. I wish
we gather our efforts on one tool like perf but I don't want to force
everyone to this path. So I personally agree with that library
to be standalone.

Thus I think we are stuck again.

Now libtraceevent is perhaps going to become a separate project. I don't
know.

By backporting and sending this libparsevent patch series, I felt pretty
eager in that we could make a great step toward the tracing code unification.

But now with the current state of the picture, I'm worried about
the future of tracing in perf tools. I don't want to spend my time to backport
the features of the parse event code because I refuse to hack around
politics disagreements. So probably the current code is going to rot. Unless
somebody wants to handle this unpleasant task.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists