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 mailinglist (and I truly regret because it should have been debated publicly).

Ingo doesn't seem to want this library outside perf in order to avoidthe 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 haveboth tools unified as well. But he wants to keep libparseevent asa generic standalone library.

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

Thus I think we are stuck again.

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

By backporting and sending this libparsevent patch series, I felt prettyeager 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 aboutthe future of tracing in perf tools. I don't want to spend my time to backportthe features of the parse event code because I refuse to hack aroundpolitics disagreements. So probably the current code is going to rot. Unlesssomebody wants to handle this unpleasant task.