From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752501AbcF1LwN (ORCPT ); Tue, 28 Jun 2016 07:52:13 -0400 Received: from szxga03-in.huawei.com ([119.145.14.66]:52980 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752190AbcF1LvW (ORCPT ); Tue, 28 Jun 2016 07:51:22 -0400 Subject: Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script To: Alexei Starovoitov References: <1466940078-65581-1-git-send-email-hekuang@huawei.com> <20160626204806.GA34060@ast-mbp> CC: , , , , , , , , From: Hekuang Message-ID: <577263E9.6080806@huawei.com> Date: Tue, 28 Jun 2016 19:47:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160626204806.GA34060@ast-mbp> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.110.55.166] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.577263F6.00D6,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 736e7ebfb7ff0d016626b65e9dea50e5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/6/27 4:48, Alexei Starovoitov 写道: > On Sun, Jun 26, 2016 at 11:20:52AM +0000, He Kuang wrote: >> 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... Maybe I misunderstood your suggestion. Now I just let perf check bpf/core.o in kernel output directory, if it exsits, perf will link it. The missing functions referenced by bpf/core.o can be defined empty in perf. The above way leaves two minor changes in bpf/core.c: diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index b94a365..0fc6c23 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -452,7 +452,7 @@ struct bpf_prog *bpf_jit_blind_constants(struct bpf_prog *prog) * therefore keeping it non-static as well; will also be used by JITs * anyway later on, so do not let the compiler omit it. */ -noinline u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5) +noinline u64 __weak __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5) { return 0; } @@ -465,7 +465,7 @@ EXPORT_SYMBOL_GPL(__bpf_call_base); * * Decode and execute eBPF instructions. */ -static unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn) +unsigned int __bpf_prog_run(void *ctx, const struct bpf_insn *insn) { u64 stack[MAX_BPF_STACK / sizeof(u64)]; u64 regs[MAX_BPF_REG], tmp; How about this? 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. > >