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

["Wangnan (F)" <wangnan0@huawei.com>]

On 2015/5/20 4:46, Alexei Starovoitov wrote:
> On 5/19/15 9:40 AM, Arnaldo Carvalho de Melo wrote:
>> 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.
>
> agree. 'bpf:' prefix is redundant.
> To me the following syntax is fine:
> perf record --event bpf_file.o
>
> In the future it can support automatically:
> perf record --event bpf_file.c
>
> Wang, thoughts?
>

After reading the full thread I think we finally agree that the user 
interface should be

   perf record --event bpf_file.o

for event filtering case. I'll do this in next version.

Thank you.

>>> 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.
>
> if you're proposing to do something like:
> perf script bpf_file.c
> that will do event creation, filtering, aggregation, reporting
> and printing results, then it's fine.
> This is pretty much what I thought 'perf bpf run' will do.
>
>> 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 :-)
>
> not sure that's doable. The task (perf) that loaded the program in the
> step one should be still alive when 2nd part is running.
> For 'perf bpf run' use case, the whole record/report split is
> artificial. There is no need for perf.data.
> In my mind 'perf bpf run file.c' suppose to quickly compile .c,
> hook into kernel, collect and print something, then Ctrl-C of
> 'perf bpf run' should automatically stop everything.
> No perf.data anywhere. It should be quick single step
> tool for live debugging.
> At the same time 'perf record --event bpf_file.o' plus generic
> 'perf report' model works very well as well.
> They are different use cases.
>
> I guess I'm saying let's not get too much ahead of ourselves ;)
> I think Wang's current patchset is close enough to make
> 'perf record --event bpf_file.o' to be useful.
> Let's take this first step.
>