Re: Re: [RFC PATCH perf/core v2 00/16] perf-probe --cache and SDT support

[Namhyung Kim <namhyung@kernel.org>]

Hi Masami,

On Fri, Jul 17, 2015 at 12:21:42PM +0900, Masami Hiramatsu wrote:
> Now I'm thinking that we should avoid using %event syntax for perf-list
> and perf-record to avoid confusion. For example, suppose that we have
> "libfoo:bar" SDT event, when we just scanned the libfoo binary and
> use it via perf-record, we'll run perf record -e "%libfoo:bar".
> However, after we set the probe via perf-probe, we have to run
> perf record -e "libfoo:bar". That difference looks no good.
> So, I think in both case it should accept -e "libfoo:bar" syntax.

I don't remember how the SDT events should be shown to users.  Sorry
if I'm missing something here.

AFAIK an SDT event consists of a provider and an event name.  So it
can be simply 'provider:event' like tracepoints or
'binary:provider_event' like uprobes.

I like the former because it's simpler but it needs to guarantee that
it doesn't clash with existing tracepoints/[ku]probes.  So IIUC we
chose the '%' sign to distinguish them.  But after setting a probe at
it, the group name should be the binary name.  So the whole event name
might be changed, and this is not good.

So we should use the latter form.  But in this case, I think we need a
way to distinguish provider and event names.  Since the provider name
also can include '_' characters in it.  And maybe it still needs to
distinguish an SDT event and its probe for some reason.  In that case,
we might use 'sdt:provider_event' form or something like that.

Thanks,
Namhyung


> 
> In this series I've introduced %event syntax only to recall cached event
> setting explicitly, because perf-probe is a lower layer tool to set up
> new event. IMO, perf-list and perf-record should be higher tools which
> handle abstract events.