lkml.org 
[lkml]   [2016]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v2 00/26] perf tools: Support uBPF script
From
Date
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.
>
>


\
 
 \ /
  Last update: 2016-06-27 05:01    [W:0.122 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site