Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script

[Hekuang <hekuang@huawei.com>]

hi

在 2016/6/27 4:48, Alexei Starovoitov 写道:
> On Sun, Jun 26, 2016 at 11:20:52AM +0000, He Kuang wrote:
>> This patchset is based on Wang Nan's v1:
>>       http://thread.gmane.org/gmane.linux.kernel/2203717/focus=2203707
>>
>> """
>>    This patch set allows to perf invoke some user space BPF scripts on
>>    some point. uBPF scripts and kernel BPF scripts reside in one BPF
>>    object.  They communicate with each other with BPF maps. uBPF
>>    scripts can invoke helper functions provided by perf.
>>    
>>    At least following new features can be achieved based on uBPF
>>    support:
>>    
>>     1) Report statistical result:
>>
>>        Like DTrace, perf print statistical report before quit. No need
>>        to extract data using 'perf report'. Statistical method is
>>        controled by user.
>>    
>>     2) Control perf's behavior:
>>
>>        Dynamically adjust period of different events. Policy is defined
>>        by user.
>> """
>>
>> and modified by following the reviewers' suggestions.
>>
>> v1-v2:
>>
>>    - Split bpf vm part out of kernel/bpf/core.c and link to it instead
>>      of using ubpf library(Suggested by Alexei Starovoitov). And add
>>      runtime bounds check just like ubpf library does.
> hmm. I don't think I suggested to hack bpf/core.c into separate file
> and compile it for userspace...
"""

Also ubpf was written from scratch with apache2, while perf is gpl,
so you can just link kernel/bpf/core.o directly instead of using external
libraries.
"""
This is your comment on ubpf v1 thread.

I thought you was suggesting to use code in kernel/bpf/core.o,
but because there're difference in __bpf_prog_run() between userspace
and kernel, for example the __bpf_call_base is used in kernel,
in userspace we get funcs from ubpf function list, we have to modify
the existing code in kernel/bpf/core.c.

I've got the source code of 'bcc' project, but it seems that bcc does not
involve bpf virtual machine, so if we do not use 'kernel/bpf/core.o' solution,
and can't use 'ubpf' because of the license reason, any other choices?

Thank you.

> Also I think the prior experience taught us that sharing code between
> kernel and user space will have lots of headaches long term.
> I think it makes more sense to use bcc approach. Just have c+py
> or c+lua or c+c. llvm has x86 backend too. If you integrate
> clang/llvm (bcc approach) you can compile different functions with
> different backends... if you don't want to embed the compiler,
> have two .c files. Compile one for bpf target and another for native.
>
>