Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to load eBPF programs.

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Mon, May 18, 2015 at 02:05:35PM -0700, Alexei Starovoitov escreveu:
> On 5/18/15 1:44 PM, Arnaldo Carvalho de Melo wrote:
> >
> >perf record --filter, to pass a filter to tracepoints, if I could
> >instead of a filter expression pass, say, filter_bpf.o, that would seem
> >natural for me, i.e. no new option, just an alternative type of filter,
> >one way more powerful.
> ...
> >I'd say keep it in --filter, that noticing it is a bpf object would
> >dtrt:
> >
> >   perf record --filter bpf_thing.o usleep 1
> >
> 
> agree. make sense.
> The only thing is that such bpf program defines both event and filter.
> Existing --filter applies to --event, whereas this bpf_thing.o does both
> and likely kprob-ing multiple events underneath.
> I guess '--filter' still fits. Just need to document it clearly.

Humm, unsure then, because it is not a filter anymore, i.e. it is both a
filter and event selector :-\

I was thinking more like, hey, for an existing event, i.e. a place in
the kernel where it will collect something, collect if this filter
returns true. That would fit the existing --filter semantic.

 perf record --event bpf_thing.o

Looks more natural then, as it is an event that will take place when the
filter returns true, and in addition to that, it will come with a bunch
of variables, etc.

And if that is the case, then what is the difference from a kprobe
event? I.e. for the existing tooling it wouldn't matter how this event
was set up, as long as it was available via tracefs, etc. I.e. it would
be completely similar to a tracepoint, kprobe, uprobe, etc, i.e. first
set it up, expose its internals via tracefs, no changes to perf.

I must be missing something... But then it would happen when I would try
to deal with this eBPF thing, bear with me :-)

- Arnaldo