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.
