Em Mon, Jan 24, 2011 at 11:46:12PM +0100, Frederic Weisbecker escreveu:

On Mon, Jan 24, 2011 at 11:30:01PM +0100, Thomas Renninger wrote:

quoted

On Monday 24 January 2011 22:57:55 Arnaldo Carvalho de Melo wrote:

quoted

Em Mon, Jan 24, 2011 at 10:49:13PM +0100, Thomas Renninger escreveu:

... 

quoted

Using the /format file hashed as peterz said is elegant, fine grained
content based ABI number :-)

Ok thanks, I should have had a closer look at the binary format.

It may make sense at some time to provide a library so that other tools
can make use of the most convenient functions in tools/perf/utils/*
as well?

I personally wish the other way around: having Pytimechart merged in perf :)
If I remember correctly, the problem was that we don't have support for
trace_printk with perf?

But sure if more out of tree tools show up and want to use tracepoints,
we can think about librarizing it.

(Even though my secret hope is that
we build a nice one tool that can answer most tracing needs together rather
than many scattered ad hoc pieces.)

Yes, there is this conflict of tools/perf/ people coming from the
kernel, where we can change APIs as we see fit as long as we pay the
price of going over the users to fix them up.

And the desire of having something that can be used by projects living
outside the kernel source repo.

There are at least two efforts underway that are paving the way to
having something usable by third parties, Borislav Petkov's patchseries
to have some liblk/libtrace and my work for .39 to have a python perf.so
binding.

I think we should try as hard as possible to get things in tools/ so
that we have as long an experience in trying to get good abstractions as
possible before we decide on a v1 "outsiders API" :-)

- Arnaldo

P.S. Most of my work is in my perf/core branch in my git.k.o tree,
both mine and Borislavs are a wersearch away :)