Messages in this thread | | | Date | Wed, 15 Feb 2012 10:24:23 +0100 | From | Jiri Olsa <> | Subject | Re: [PATCHv4 0/9] perf tool: parser generator for events parsing |
| |
On Tue, Feb 14, 2012 at 10:03:11PM +0100, Peter Zijlstra wrote: > On Tue, 2012-02-14 at 21:57 +0100, Peter Zijlstra wrote: > > On Tue, 2012-02-14 at 21:20 +0100, Peter Zijlstra wrote: > > > OK, this one works. the attributes thing wants NULL termination. > > > Thanks > > > for mentioning that Jiri. > > > > OK, it mostly works, except: > > > > perf record -e "cpu/config=0x108000c0/upp" ./loop_1b_locks > > > > doesn't seem to work... > > This seems to come back to hardcoding config* vs including it in every > single format description. > > I prefer to have all perf_event_attr fields (of interest) hard-coded in > the parser so that we can omit them for all actual format descriptions. > > These would be: period, config, config1, config2 and stephane's new > branch_sample_type, although that might want to get a shorter name.
right, for pmu/.../ syntax there are allowed only fields from 'format' directory are so far.. with exceptions like: cycles/period=100000/
so I'll hardcode following config fields: config config1 config2 period branch_sample_type (branch, branch_type, branch_st ???)
to be used in xxx/.../ syntax
also we need to choose some strategy of format field name shadowing with hardcoded fields:
- BUILD_BUG in kernel PMU_FORMAT_ATTR - not allowed.. report error in perf runtime - allowed - hardcoded field have precedence - allowed - format field values have precedence
I'd say either allow shadowing(with whatever precedence we this is better), or have the BUILD_BUG line in kernel..
jirka
| |