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

[Hekuang]

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.