From: Will C. <wc...@re...> - 2003-05-27 16:06:40
|
There is interest in using OProfile with Eclipse as a plug-in. Rather than writing a separate set of functions to access the profiling data it would be preferable to use the existing OProfile libraries. The OProfile libraries and their interfaces are still evolving, but using the API supplied by the libraries is still preferable to replicating the functionality supplied by oprofile libraries. At some point I would expect the libraries to be made available for other applications. The question is what license is going to be used for the libraries? GPL or LGPL? Eclipse is covered by the Common Public License Version 1.0 (http://www.eclipse.org/legal/cpl-v10.html) which according to http://www.fsf.org/licenses/license-list.html is incompatible with the GPL. OProfile is linking with other libraries, e.g. bfd and iberty, and that might affect the license. -Will |
From: John L. <le...@mo...> - 2003-05-27 19:41:58
|
On Tue, May 27, 2003 at 12:06:25PM -0400, Will Cohen wrote: > There is interest in using OProfile with Eclipse as a plug-in. Rather I'd go have a look but they insist on some password crap to get at the archives. Useless. > At some point I would expect the libraries to be made available for > other applications. The question is what license is going to be used for > e.g. bfd and iberty, and that might affect the license. The binutils license is GPL so that's what we have to use. If somebody makes a backend under some other license, I wouldn't personally have a problem with dual-licensing some stuff, though I'm not sure about BSD ... But with binutils it's academic anyway. Dunno what Phil thinks regards john |
From: Will C. <wc...@re...> - 2003-05-27 20:20:57
|
John Levon wrote: > On Tue, May 27, 2003 at 12:06:25PM -0400, Will Cohen wrote: > > >>There is interest in using OProfile with Eclipse as a plug-in. Rather > > > I'd go have a look but they insist on some password crap to get at the > archives. Useless. This was some discussion at Red Hat. I don't know if it there is any mention of it on the Eclipse archives. I find the passwd required access annoying also. >>At some point I would expect the libraries to be made available for >>other applications. The question is what license is going to be used for > > >>e.g. bfd and iberty, and that might affect the license. > > > The binutils license is GPL so that's what we have to use. If somebody > makes a backend under some other license, I wouldn't personally have a > problem with dual-licensing some stuff, though I'm not sure about BSD > ... > > But with binutils it's academic anyway. > > Dunno what Phil thinks > > regards > john Another concern is the name collisions in the libraries. There is already a /usr/lib/libutil.a. I would suggest that the name libutil.a mutate to liboputil.a. While I am at it libutil++.a becomes liboputil++.a, libabi.a becomes libopabi.a, and libpp.a becomes liboppp.a -Will |
From: John L. <le...@mo...> - 2003-05-27 20:49:05
|
On Tue, May 27, 2003 at 04:20:43PM -0400, Will Cohen wrote: > This was some discussion at Red Hat. I don't know if it there is any Oh OK. > Another concern is the name collisions in the libraries. There is > already a /usr/lib/libutil.a. I would suggest that the name libutil.a > mutate to liboputil.a. While I am at it libutil++.a becomes > liboputil++.a, libabi.a becomes libopabi.a, and libpp.a becomes liboppp.a We don't need that. libutil and friends are never supposed to be separately installed libraries. We would basically have two installed libraries: libodb and liboprofile. Or something similar Phil, they'd basically have to have a process-level GPL boundary to be able to link to us. And I agree with you about not going the BSD route, especially given that profiler that's basically a shell around Mikael's perfctr, that goes for 600 USD john |
From: Will C. <wc...@re...> - 2003-05-28 13:42:24
|
John Levon wrote: > On Tue, May 27, 2003 at 04:20:43PM -0400, Will Cohen wrote: > > >>This was some discussion at Red Hat. I don't know if it there is any > > > Oh OK. > > >>Another concern is the name collisions in the libraries. There is >>already a /usr/lib/libutil.a. I would suggest that the name libutil.a >>mutate to liboputil.a. While I am at it libutil++.a becomes >>liboputil++.a, libabi.a becomes libopabi.a, and libpp.a becomes liboppp.a > > > We don't need that. libutil and friends are never supposed to be > separately installed libraries. We would basically have two installed > libraries: libodb and liboprofile. Or something similar Having a liboprofile is fine. I was just starting out with the libraries that were currently available. > Phil, they'd basically have to have a process-level GPL boundary to be > able to link to us. > > And I agree with you about not going the BSD route, especially given > that profiler that's basically a shell around Mikael's perfctr, that > goes for 600 USD Yes, I understand the concern about closed source software taking advantage of the interfaces, but not providing anything in return. This is one of the reasons that GCC doesn't provide a "gcc library" or dump out or read in complete RTL. -Will |
From: John L. <le...@mo...> - 2003-05-28 15:18:13
|
On Wed, May 28, 2003 at 09:42:10AM -0400, Will Cohen wrote: > Yes, I understand the concern about closed source software taking > advantage of the interfaces, but not providing anything in return. This > is one of the reasons that GCC doesn't provide a "gcc library" or dump > out or read in complete RTL. Well, we've got no problem with dumping an XML document of the requested profile. It should even be relatively easy to do. Perhaps the eclipse plugin could just use that ? regards john |
From: Will C. <wc...@re...> - 2003-05-28 15:22:58
|
I am not that familiar with xml. Do you have a good pointer to xml? Is there a specification on how to parse the xml from the profiling tools? How would the plug-in select the data it wants rendered? Just invoke oprofpp/op_time with the options it is interested in and state the output should be in xml? -Will John Levon wrote: > On Wed, May 28, 2003 at 09:42:10AM -0400, Will Cohen wrote: > > >>Yes, I understand the concern about closed source software taking >>advantage of the interfaces, but not providing anything in return. This >>is one of the reasons that GCC doesn't provide a "gcc library" or dump >>out or read in complete RTL. > > > Well, we've got no problem with dumping an XML document of the requested > profile. It should even be relatively easy to do. > > Perhaps the eclipse plugin could just use that ? > > regards > john |
From: John L. <le...@mo...> - 2003-05-28 15:30:02
|
On Wed, May 28, 2003 at 11:22:44AM -0400, Will Cohen wrote: > I am not that familiar with xml. Do you have a good pointer to xml? Is Basically we'll produce output a bit like : <profile> <symbolsummary> <name>do_stuff</name> <samples>45454</samples> <percentage>45.4</percentage> </symbolsummary> </profile> > How would the plug-in select the data it wants rendered? Just invoke > oprofpp/op_time with the options it is interested in and state the > output should be in xml? Yep (well opreport ;) I assume eclipse has some XML parser component already... I'd be surprised if it didn't but I don't know anything about it. This had the disadvantage of being slooow of course. regards john |
From: Philippe E. <ph...@wa...> - 2003-05-27 19:59:27
|
Will Cohen wrote: lawyer things are my point of view (and it's very hard for a non-native spekear to interpret interaction between GPL and CPL), I dunno what John think about that. > There is interest in using OProfile with Eclipse as a plug-in. Rather > than writing a separate set of functions to access the profiling data it > would be preferable to use the existing OProfile libraries. The OProfile > libraries and their interfaces are still evolving, but using the API > supplied by the libraries is still preferable to replicating the > functionality supplied by oprofile libraries. Actually we are about to change completely the interface for the incoming 0.6, probably in less than one or two month. The sample file format itself doesn't change. > > At some point I would expect the libraries to be made available for > other applications. The question is what license is going to be used for > the libraries? GPL or LGPL? Eclipse is covered by the Common Public > License Version 1.0 (http://www.eclipse.org/legal/cpl-v10.html) which > according to http://www.fsf.org/licenses/license-list.html is > incompatible with the GPL. OProfile is linking with other libraries, > e.g. bfd and iberty, and that might affect the license. http://www-106.ibm.com/developerworks/library/os-cplfaq.html # 12 seems to imply you can't do that since oprofile and all librairies are already GPL'ed but surely eclipse already link with LGPL'ed shared libs so I don't think Eclipse can use source code but we can provide librairies as shared libs. See also #19 a quick and dirty example of such wrapper for sample file open/close/read (no need to provide a write interface), only to get the figure how I see such interface. #ifdef __cplusplus extern "C" { #endif /* C interface, implemented in term of c++ interface below */ struct op_sample_file; struct op_sample_file_iterator; op_sample_file * open(char const * filename); void close(op_sample_file *); // need more though bool error(op_sample_file *); op_sample_file_iterator * start_iteration(op_sample_file const *); op_sample_file_iterator * next(op_sample_file_iterator *); bfd_vma eip(op_sample_file_iterator *); unsigned int count(op_sample_file_iterator *); #ifdef __cplusplus } #endif /* C++ interface */ #ifdef __cpluscplus struct op_sample_file { public: op_sample_file(std::string const & filename); // etc. private: struct op_sample_file_imp * imp; }; // etc. struct op_sample_file_iterator { ... }; #endif i.e. only provide interface and pointer to data-less object, (except pointer to implementation), no #include of our own interface, no macro, no virtual function. Note than sample file interface is the most easy, writing such interface to handle sample filename, retrieve and select sample filename etc. is much harder. One way to see if such interface is well designed is to verify than the same interface would be used for both pp-interface-branch and cvs trunk. At lawyer point of view, we have a problem, we must allow eclipse to use them, gpl'ed code to use them too but I think this will imply that commercial product could use the interface to link to Oprofile which I don't like at all, movement ? regards, Phil |