From: William C. <wc...@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 oprofile data. 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 other software? -Will |
From: John L. <le...@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 maintenance 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 pain... regards, john |