On 27 July 2016 at 13:26, Jiri Olsa <[email protected]> wrote: > On Wed, Jul 27, 2016 at 11:59:50AM -0600, Mathieu Poirier wrote: > > SNIP > >> > -PE_DRV_CFG_TERM >> > +'@' PE_NAME '=' PE_NAME >> > { >> > struct parse_events_term *term; >> > >> > ABORT_ON(parse_events_term__str(&term, >> > PARSE_EVENTS__TERM_TYPE_DRV_CFG, >> > - $1, $1, &@1, NULL)); >> > + $2, $4, &@2, &@4)); >> > $$ = term; >> > } >> > >> >> The problem here is that the correlation between the first and the >> second PE_NAME is lost and instead of seeing "PE_NAME=PE_NAME", the >> kernel only gets the value associated with the second PE_NAME. >> >> For example, >> >> -e event/@cfg1=value1,@cfg2=value2/ ... >> >> The above code will send "value1" and "value2" to the kernel driver >> where there is no way to know what configurable the values correspond > > hum.. you get the 'cfg1' and 'cfg2' strings in $1 no?
Indeed you do. Macro ADD_CONFIG_TERM in function get_config_terms() only account for the __val parameter and struct parse_events_term::config is completely ignored. We could concatenate the fields before calling ADD_CONFIG_TERM() but between that and freeing the reserved memory, I think it is cleaner to let flex do the work. Mathieu > > jirka > >> to. To go around that we'd have to concatenate $2 and $4 in function >> parse_events_term__str() (or new_term()) when @type_term == >> PARSE_EVENTS__TERM_TYPE_DRV_CFG, something that definitely looks >> hackish to me. >> >> Thanks, >> Mathieu
