From patchwork Mon Dec 14 04:39:40 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Nan X-Patchwork-Id: 58321 Delivered-To: patch@linaro.org Received: by 10.112.73.68 with SMTP id j4csp1242628lbv; Sun, 13 Dec 2015 20:40:27 -0800 (PST) X-Received: by 10.67.5.40 with SMTP id cj8mr42354611pad.98.1450068027754; Sun, 13 Dec 2015 20:40:27 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 13si9919798pft.108.2015.12.13.20.40.27; Sun, 13 Dec 2015 20:40:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752398AbbLNEkY (ORCPT + 28 others); Sun, 13 Dec 2015 23:40:24 -0500 Received: from szxga03-in.huawei.com ([119.145.14.66]:2974 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752240AbbLNEkX (ORCPT ); Sun, 13 Dec 2015 23:40:23 -0500 Received: from 172.24.1.48 (EHLO szxeml427-hub.china.huawei.com) ([172.24.1.48]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id BSS19445; Mon, 14 Dec 2015 12:40:10 +0800 (CST) Received: from [127.0.0.1] (10.111.66.109) by szxeml427-hub.china.huawei.com (10.82.67.182) with Microsoft SMTP Server id 14.3.235.1; Mon, 14 Dec 2015 12:40:00 +0800 Message-ID: <566E480C.7030702@huawei.com> Date: Mon, 14 Dec 2015 12:39:40 +0800 From: "Wangnan (F)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexei Starovoitov CC: pi3orama , Arnaldo Carvalho de Melo , , , , , Alexei Starovoitov , Masami Hiramatsu Subject: Re: [PATCH v4 09/16] perf tools: Enable indices setting syntax for BPF maps References: <1449541544-67621-1-git-send-email-wangnan0@huawei.com> <1449541544-67621-10-git-send-email-wangnan0@huawei.com> <20151211121145.GP17996@kernel.org> <20151211121521.GQ17996@kernel.org> <20151211182157.GC59096@ast-mbp.thefacebook.com> <566E3728.2090306@huawei.com> <20151214042820.GA17953@ast-mbp.thefacebook.com> In-Reply-To: <20151214042820.GA17953@ast-mbp.thefacebook.com> X-Originating-IP: [10.111.66.109] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.566E482C.002B, 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: 73d83382a4f202753780ff66bd3688e6 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/12/14 12:28, Alexei Starovoitov wrote: > On Mon, Dec 14, 2015 at 11:27:36AM +0800, Wangnan (F) wrote: >> >> On 2015/12/12 2:21, Alexei Starovoitov wrote: >>> On Fri, Dec 11, 2015 at 08:39:35PM +0800, pi3orama wrote: >>>>> static u64 (*bpf_ktime_get_ns)(void) = >>>>> (void *)5; >>>>> static int (*bpf_trace_printk)(const char *fmt, int fmt_size, ...) = >>>>> (void *)6; >>>>> static int (*bpf_get_smp_processor_id)(void) = >>>>> (void *)8; >>>>> static int (*bpf_perf_event_output)(void *, struct bpf_map_def *, int, >>>>> void *, unsigned long) = >>>>> (void *)23; >>>>> >>>>> Where can I get this magical mistery table? Could this be hidden away in >>>>> some .h file automagically included in bpf scriptlets so that n00bies >>>>> like me don't have to be wtf'ing? >>>>> >>>> They are function numbers defined in bpf.h and bpf-common.h, but they are Linux >>>> headers. Directly include them causes many error for llvm. Also, the function >>>> prototypes are BPF specific and can't included in Linux source. We should have >>>> a place holds those indices and prototypes together. >>> wait, what kind of errors? >>> they are in uapi, so gets installed into /usr/include eventually >>> and I haven't seen any erros either with gcc or clang. >>> >> Sorry. I saw error because I use >> >> #include >> >> It is okay if I use >> >> #include > then let's use that instead of copy-paste. thanks And what do you think about the BPF function prototype? Should we put them into kernel headers? What about:: diff --git a/include/uapi/linux/bpf_functions.h b/include/uapi/linux/bpf_functions.h new file mode 100644 index 0000000..3a562d4 --- /dev/null +++ b/include/uapi/linux/bpf_functions.h @@ -0,0 +1,2 @@ +DEFINE_BPF_FUNC(void *, map_lookup_elem, void *, void *) +DEFINE_BPF_FUNC(int, map_update_elem, void *, void *, void *, int) [SNIP] diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 9ea2d22..2f2f05f 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -133,143 +133,23 @@ union bpf_attr { }; } __attribute__((aligned(8))); +#define DEFINE_BPF_FUNC(rettype, name, arglist...) BPF_FUNC_##name + +enum bpf_func_id { +BPF_FUNC_unspec, +#include "bpf_functions.h" +__BPF_FUNC_MAX_ID, +}; + +#ifdef __BPF_SOURCE__ +#undef DEFINE_BPF_FUNC +#define DEFINE_BPF_FUNC(rettype, name, arglist...) static rettype (*name)(arglist) = (void *)BPF_FUNC_##name +#include "bpf_functions.h" +#endif /* integer value in 'imm' field of BPF_CALL instruction selects which helper * function eBPF program intends to call */ enum bpf_func_id { - BPF_FUNC_unspec, [SNIP] And when compiling BPF source file we add a __BPF_SOURCE__ directive? Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/