Em Thu, Mar 08, 2012 at 04:28:51 PM +0900, Namhyung Kim escreveu:Changing default value of perf_guest back to false caused problems on old
kernels and its fix bc76efe64533 ("perf tools: Handle kernels that don't
support attr.exclude_{guest,host}") worked well for perf record/top.
But I've just realized that using specific events on perf stat makes same
kind of troubles too. It's because the parse_events calls event_attr_init
for all events so that it would have exclude_guest set.
Instead of fixing perf stat, I thought that changing perf_evsel__open()
is more appropriate. Please take a look and give comments - especially
on ->time_not_needed handling in builtin-record.c (I guess the original
code had a bug) and checking ->sample_id_all_missing inside of
perf_evsel__config (I believe checking it before perf_evsel__open is
meaningless since it will always have the same value - so I dropped it).
One problem here is to have all those pr_debug calls down in the
perf_evlist class, they need to be better conveyed to the user, and that
depends on the kind of interface being used (stdio, TUI, GTK).
One approach tried till the GTK patch was proposed was to just check the
value of perf_browser or some UI fops table to do it at that level.
But Pekka argued that we should allow tool writers to have more freedom
than that, i.e. handle things as flexibly as possible.
The way to do that, that I discussed with David Ahern some time ago, was
to have per class errno enums, and then a per class strerror (really an
strerror_r) that would map the integer error number to an string.
Doing that we would also avoid having to bloat the python binding (or
libperf at some point) with the pr_debug, etc machinery.
For instance, with your patch applied, try running
tools/perf/python/twatch.py :-)
Other than that, yeah, I think perf_attr_conf is needed and the rest of
the patch looks ok, will look again after you address the above
comments,
Thanks!
- Arnaldo