Em Mon, Nov 28, 2011 at 06:43:35AM -0800, Arjan van de Ven escreveu: > > perf_evlist is what you call perf_bundle and perf_evsel is what you call > > perf_event in powertop.
> > That part of the API should be ok for wider use and is in fact exported > > in the python binding. > > I don't care about the snake language. I haven't suggested that you use any other language than C. What I tried to say was that the way the python binding was written provides an initial libperf.so, just that it is not exposed yet. That is, the subset of C files there is (or should be) untangled from all the rest of tools/perf. > frankly all that's missing is a "safe" accessor library as Steve has > promised will appear. > that library really needs to be a proper shared library and not come > from/with the kernel package, so that distributions can independently > package it properly. I can probably have something like: [acme@emilia linux]$ make help | grep perf perf-tar-src-pkg - Build perf-3.2.0-rc1.tar source tarball perf-targz-src-pkg - Build perf-3.2.0-rc1.tar.gz source tarball perf-tarbz2-src-pkg - Build perf-3.2.0-rc1.tar.bz2 source tarball perf-tarxz-src-pkg - Build perf-3.2.0-rc1.tar.xz source tarball [acme@emilia linux]$ i.e.: $ make libperf-tar-src.pkg > (and this obviously needs to at least look at the things that the > systemd guys pointed us at at the kernel summit) Yes, I'll take that into account. > I'm not interested if the code for a library is somewhere deep in the > kernel source code, not installed by default in distros (or tied in with > loads of other mess) and/or uses the kernel makefiles/etc like perf does. Right, I'm working on that, don't know when it will get to the point you'd consider using it, but I'll try to address your concerns in the process. - Arnaldo _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
