[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1324378070.24621.32.camel@twins>
Date: Tue, 20 Dec 2011 11:47:50 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Jiri Olsa <jolsa@...hat.com>
Cc: acme@...hat.com, mingo@...e.hu, paulus@...ba.org,
cjashfor@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] perf, tool: Add parser generator for events parsing
On Tue, 2011-12-20 at 11:31 +0100, Jiri Olsa wrote:
> On Fri, Dec 16, 2011 at 03:03:16PM +0100, Peter Zijlstra wrote:
> > On Fri, 2011-12-16 at 15:02 +0100, Peter Zijlstra wrote:
> > > > event_tracepoint: PE_NAME_TP ':' PE_NAME_TP modifier
> > > > event_raw: PE_SEP_RAW PE_VALUE modifier
> > > > event_numeric: PE_VALUE ':' PE_VALUE modifier
> > > > event_symbolic: PE_NAME_SYM modifier
> > > > event_generic_hw: PE_NAME_CACHE_TYPE '-' PE_NAME_CACHE_OP_RESULT '-' PE_NAME_CACHE_OP_RESULT modifier |
> > > > PE_NAME_CACHE_TYPE '-' PE_NAME_CACHE_OP_RESULT modifier |
> > > > PE_NAME_CACHE_TYPE modifier
> > > > event_breakpoint: PE_SEP_BP ':' PE_VALUE event_breakpoint_type modifier
> > > > event_breakpoint_type: PE_MODIFIER_BPTYPE | empty
> > > > modifier: PE_MODIFIER_EVENT | empty
> > >
> > > This isn't complete, we need means of specifying
> > > perf_event_attr::config[12] when specifying a raw event.
> >
> > Also, it might make sense to think about how to specify sysfs events
> > (which don't exist yet).
>
> any idea/details/specifics how they might look like? ;)
The current idea is that they'd live in a place like:
/sys/bus/event_source/devices/$pmu/events/$event
and when you read them they contain a full event_raw style string so you
could do things like:
perf record -e `cat $sysfsfile` or so
(or maybe without the 'r' prefix).
The idea was to have some $pmu:$event like syntax, but seeing that ':'
is already used quite a lot, there's maybe a more suitable separator.
Maybe '/' would do, yielding things like cpu/instructions.
Then again, it might make sense to restructure the syntax without
considerations for the status quo and see if we can come up with
something a little more consistent, the above event_* things are quite a
hodge podge, syntax wise.
While I appreciate that they are the result of organic growth, it
doesn't mean we shouldn't try and restructure stuff once in a while when
it makes sense.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists