Messages in this thread | | | Subject | Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script | From | Hekuang <> | Date | Mon, 27 Jun 2016 10:10:42 +0800 |
| |
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. > >
| |