Em Wed, May 20, 2015 at 01:04:48AM +0900, Namhyung Kim escreveu:
On Tue, May 19, 2015 at 10:44:58AM -0300, Arnaldo Carvalho de Melo wrote:
Em Mon, May 18, 2015 at 02:45:58PM -0700, Alexei Starovoitov escreveu:
On 5/18/15 2:20 PM, Arnaldo Carvalho de Melo wrote:
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.
well, I think --event fits a bit less than --filter ;)
Both not ideal.
I thought --event was more suited, as it states what is the event, and
when it should happen, i.e. --filter is about reducing the frequency of
something well defined, i.e. an existing --event.
If we go with 'perf record' rather than 'perf bpf record', I agree
that --event option is more natural than --filter. The --event option
says that it will record - or enable, at least - a (kprobe) event for
bpf programs in it and then do something with it. :)
Maybe something like this?
perf record --event bpf:/path/to/object
The syntax maybe one of many, say if it sees a ".o" suffix in the even
name, look if the provided event name is a file and if this file has the
ELF header, whatever.
Oh, this looks like an interesting approach.. are you saying something
like below?
No, those are way too many steps :-)
What 'perf script' does? Right now you can ask for a script to run and
it will both start 'perf record' with the proper events, and then
"immediately" consume it, piping the output of the 'record' "script" to
the consumer, that is 'perf script' itself running an interpreter, perl
or python.
I.e. the first part, say, failed-syscalls-record, would be done
internally, loading the bpf object, etc, the second part would be the
event massaging, but done in a C subset :-)