From: William Cohen <wcohen@nc...> - 2005-01-27 16:40:31
There is currently an Eclipse (http://www.eclipse.org/) plugin to
control OProfile and navigate OProfile data. To make this work a number
of the header files and some of the libraries were installed on the
system. This is implemented with some hacks in the oprofile spec file to
explicitly install the files. The headers and libraries are packaged
into a seperate oprofile-devel rpm. If we want people to write software
to navigate the oprofile data, it might be good to put those types of
changes in the makefiles of OProfile.
The author of the eclipse plugin, Keith Sietz has also made acouple
suggestions to make it easier to have external program to navigate the
1) add declaration of create_file_list (in libutil++) to header file
2) add parse_filename.h (in libpp) to oprofile-devel in some way
What are peoples' thoughts on making OProfile easier to interface to
From: John Levon <levon@mo...> - 2005-01-28 10:25:07
On Thu, Jan 27, 2005 at 11:39:47AM -0500, William Cohen wrote:
> What are peoples' thoughts on making OProfile easier to interface to
> other software?
I think it's a worthy goal, but requires work. In particular, the "take
what we have and dump it for the world to see" approach is not
acceptable - these are internal libraries and headers, and have zero
design input from the "external stuff needs to use this" point of view.
The work that needs to be done is as follows:
1) identify the requirements of clients of liboprofile
2) identify and create suitable entry points
3) design and create those entry points suitable for long-term library
4) build oprofile.h, liboprofile.so, including mapfiles etc.
I certainly encourage you to do this work if you're needing this;
continuing to use the internal libraries and headers will bring you