[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151214055123.GA18340@ast-mbp.thefacebook.com>
Date: Sun, 13 Dec 2015 21:51:25 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: "Wangnan (F)" <wangnan0@...wei.com>
Cc: pi3orama <pi3orama@....com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
namhyung@...nel.org, linux-kernel@...r.kernel.org,
mingo@...nel.org, lizefan@...wei.com,
Alexei Starovoitov <ast@...nel.org>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Subject: Re: [PATCH v4 09/16] perf tools: Enable indices setting syntax for
BPF maps
On Mon, Dec 14, 2015 at 12:39:40PM +0800, Wangnan (F) wrote:
>
> And what do you think about the BPF function prototype? Should we put them
> into kernel headers? What about::
> +#define DEFINE_BPF_FUNC(rettype, name, arglist...) static rettype
> (*name)(arglist) = (void *)BPF_FUNC_##name
tldr: let's keep it as a part of user headers until better
solution found.
frankly
static void *(*bpf_map_lookup_elem)(void *map, void *key) =
(void *) BPF_FUNC_map_lookup_elem;
was llvm hack that I thought will be fixed quickly.
That was the easiest way to make C/llvm/bpf_loader to agree on
passing 'bpf_call #num' insn into the kernel.
It works, but it works only with -O2 and higher.
At lower optimization levels llvm generates load of constant
into register and indirect call by register, so that's not suitable
as clean api. bcc with clang::rewriter can solve it, but we don't
want to always depend on that, so currently it's a status quo.
Don't mess with what ain't broken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists