Messages in this thread | | | Date | Fri, 27 Jan 2012 13:32:44 +0100 | From | Jiri Olsa <> | Subject | Re: [PATCH 5/9] perf: Add sysfs format attribute for pmu device |
| |
On Thu, Jan 26, 2012 at 05:26:49PM +0100, Peter Zijlstra wrote: > On Mon, 2012-01-16 at 13:31 +0100, Jiri Olsa wrote: > > Adding 'format' attribute for pmu device that contains > > a syntax description on how to construct raw events. > > > > The event configuration is described in following > > struct pefr_event_attr attributes: > > > > config > > config1 > > config2 > > > > Each line of the format file describes mapping of name > > and bitfield definition within one of abve attributes. > > > > eg: > > event config:0-7 > > umask config:8-15 > > usr config:16 > > os config:17 > > edge config:18 > > any config:21 > > inv config:23 > > cmask config:24-31 > > > > Line syntax: > > line: NAME config ':' bits > > config: 'config' | 'config1' | 'config2" > > bits: bits ',' bit_term | bit_term > > bit_term: VALUE '-' VALUE | VALUE > > > > Adding event_format callback to the struct pmu, which provides > > the format information. The pmu shall override this function > > and provide its own specific format information. > > > > If not overloaded the default format information is used: > > > > config config:0-63 > > config1 config1:0-63 > > config2 config2:0-63 > > Shouldn't config[012] be hard-coded like period? They are struct > perf_event_attr members after all and it doesn't really make sense to > have them dynamic if we're going to have to add them to all pmu/format > things.
Well, let me clarify that config[12] and 'period' are different stuff. Also I remember you asked me about the config terms namespace in some other email and I forgot to answer :)
So, while period is event term that user can specify in the event config section like: cycles/period=100000/
the config[12] are values that are specified in the format definitions as values that are changed by event terms.. like: config1:1,6-10,44
Now for event terms.. whatever term name is specified in the pmu format definition, it is considered as valid term, when the 'pmu' event is configured.. eg events like: cpu/krava=1/u
Apart from that we recognize the term 'period', which could be specified only for symbolic events so far: cycles/period=100000/
So there can't be name clash between 'period' term and the rest so far. Once we would like to have say 'period' term inside 'pmu' events like: cpu/krava=1,period=1000/u
we would need to consider some namespace rules or smth.
Now for config[12] formats.. they are parsed as simple strings and 'hardcoded' in function format_value. I think what you suggest is to 'hardcode' them into the grammar... right?
So instead of using rule: format_term: PP_NAME ':' bits
there'll be 3 rules like:
format_term: 'config':' bits format_term: 'config1' ':' bits format_term: 'config2' ':' bits
I dont have strong feelings one way or the other... but since we already have the parser in place we could use it.. ehm :)
thanks, jirka
| |