Messages in this thread | | | Date | Mon, 6 Oct 2014 21:53:49 +0200 | From | Borislav Petkov <> | Subject | Re: perf & rasd integration plan |
| |
On Mon, Oct 06, 2014 at 04:12:27PM -0300, Arnaldo Carvalho de Melo wrote: > Right, and it is being a great exercise, thanks for the patience so far > ;-)
I know, this is your secret agenda to keep me at bay working on this! :-P
> Looking at those ifdefs we see things that are specific to tools/perf/, > like perf_evsel having a struct hists embedded... I.e. that is of no > interest whatsoever (so far) to rasd, and in turn pulls other object > files. > > So I think that right now we need to look at those ifdefs and go on > making what is in tools/perf/util/ stop using it somehow, so that what > then gets moved to tools/lib/api/perf/ (I guess this is where it should > be, opinions?) have that sorted out. > > I.e. what goes to tools/lib/api/perf/ is what is common to the needs of > tools/perf/ and rasd (wherever it may roam). > > Perhaps something like I did for sock/inet_sock/inet_connection_sock > ages ago... I.e. the tools that want a hists will have a > > struct hists_evsel { > struct perf_evsel evsel; > struct hists hists; > }; > > etc. > > Experimenting with that, as it is the only thing ifdefed out in rasd's > copy of evsel.h...
Right, this all reads like it is going in the right direction but the more important question IMO is are we doing a libperf or are we still doing tools/lib/api/perf/ of single object files to which people can link?
Because if it is the second - and it sounds to me like it is - how do you propose we link with external projects? IOW, if I want to have rasd build *without* the kernel tree, is a simple
cp -r tools/lib/api/ <my_project>/path/to/perf/lib/
work?
I mean, I don't know and I'm just asking. Is that the proposed way? Are we fine with that? Do we want something different, maybe even a lib? Is it time for a lib even?
Because the whole perf functionality is being cravingly ogled by other users - I know Matt wants it for cache QoS or whatever it is called and there are probably a whole lot of projects which would like to process events programatically in userspace.
So what I'm saying is, we probably should have a nice clean way to be able to share that code with external projects instead of external projects duplicating and building a whole library around perf_event_open() and the likes...
Just a couple of thoughts...
-- Regards/Gruss, Boris.
Sent from a fat crate under my desk. Formatting is fine. --
| |