From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752159AbcF1O5M (ORCPT <rfc822;w@1wt.eu>);
	Tue, 28 Jun 2016 10:57:12 -0400
Received: from mail-pa0-f65.google.com ([209.85.220.65]:33769 "EHLO
	mail-pa0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751673AbcF1O5K (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 28 Jun 2016 10:57:10 -0400
Date: Tue, 28 Jun 2016 16:57:04 +0200
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Hekuang <hekuang@huawei.com>
Cc: acme@kernel.org, peterz@infradead.org, mingo@redhat.com, jolsa@redhat.com,
        brendan.d.gregg@gmail.com, ast@kernel.org,
        alexander.shishkin@linux.intel.com, wangnan0@huawei.com,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 00/26] perf tools: Support uBPF script
Message-ID: <20160628145702.GA48906@ast-mbp.thefacebook.com>
References: <1466940078-65581-1-git-send-email-hekuang@huawei.com>
 <20160626204806.GA34060@ast-mbp>
 <577263E9.6080806@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <577263E9.6080806@huawei.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jun 28, 2016 at 07:47:53PM +0800, Hekuang wrote:
> 
> 
> 在 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.

yes. that's what I meant.
Note that this is still soft dependency on kernel, so things will break
eventually.

> 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)

this part I don't understand. Why do you need to change it?

>  {
>         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)

yes. that is good.

> >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.

I still think that what two .c files without embeded llvm or
one .c with embedded is a better way.
You'll have full C that is fast on x86 or arm instead of
executing things in ubpf.
Or use py/lua wrappers. Equally easy.