From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D956141E0C; Mon, 13 Mar 2023 15:55:47 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 759C240E03; Mon, 13 Mar 2023 15:55:47 +0100 (CET) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mails.dpdk.org (Postfix) with ESMTP id 0E43F406BC for ; Mon, 13 Mar 2023 15:55:47 +0100 (CET) Received: by mail-pl1-f182.google.com with SMTP id ix20so6733493plb.3 for ; Mon, 13 Mar 2023 07:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678719346; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SU2rLv9VeDW1cwCReoB/BQSEEYTJiEncWlQaVLj4bXU=; b=d+BNlEgIwN55Tt/0L+WYEjnupMEafTsoiLWVt40wcFoi4C3dH4ynUq8Le0cIeFoCIa GFg6GNPsTcV+QfpuNI+p0YcECrvIgSemTIEKmnl7eAtrPAukhKMO8h5phHGNJRmC2lSP VWjNbgrM7NsT1GcqC6B1xWI9yLmYHIaGPGaNrQa+Mh5QFw7WyhwhFT9ZM+edHqrP8gyq tMf7lTzXKGuT7pRECWa4k98UUSFXSviionwi9PyRDpuB0oDYt6RPDiOpSrrubKIu8hEH x3qtxCG1VRQqaAEuf1CJmHPOcyy2gFzZRdgYw+afj7G/+GuWJAFvqtLT1q3xDXhHUsZ3 uYOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678719346; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SU2rLv9VeDW1cwCReoB/BQSEEYTJiEncWlQaVLj4bXU=; b=xvA2DdauNIS+Lt0opMziftMfL4C7nBLJGIk6QnB2DLsfQdieYZOB20KCCHSzAvCSma daIS25ZvLYf9JTLynG9bAEpRevzCu/CYezTiltMnc/EpQs+bsXju4+aG4CY2HNZAU9/1 NVkN+Ah+HxayPO96GRFqbM+/pyfJQWsigK4kIkAXi4X91Z4tk8VVRLACuYeixOK/flWv OkIbdPsa8Zv4Gubs45g3rjfctxwfRCDQxjRfwsCwsB3HB52xMQOgQBfGch5AL+jJ1Jc0 Is9PDLjZlG9wCY6t+ru894PcXvEEcZLoZG4Tnpxt8YIdfBtPJnW11W6U5Pk7LDNb8mfV tmmw== X-Gm-Message-State: AO0yUKX8DeGZKahL7cV6+6xFC1amdOsq6P3Nz2dGD6PVlSicQg8wZ85T yculQz5VbR0tzKyl1Q5LYLY7UdMhlEVeVtPKrSg= X-Google-Smtp-Source: AK7set+RPcdrGTghFwoOxIbPxsxVX8wzX9Yp+08lSiT1OWb2tRoC3N3ewW3RX/atbX7TPtPWh3OQtUGfCHwaq1zomCg= X-Received: by 2002:a17:903:643:b0:1a0:4ff0:e2f1 with SMTP id kh3-20020a170903064300b001a04ff0e2f1mr1183077plb.7.1678719346091; Mon, 13 Mar 2023 07:55:46 -0700 (PDT) MIME-Version: 1.0 References: <20230306154216.41154-1-mars14850@gmail.com> <20230312062021.7349-1-mars14850@gmail.com> <948b18da-3e41-c65c-7d47-b49ba6a4d810@yandex.ru> In-Reply-To: <948b18da-3e41-c65c-7d47-b49ba6a4d810@yandex.ru> From: "J.J. Martzki" Date: Mon, 13 Mar 2023 22:55:34 +0800 Message-ID: Subject: Re: [PATCH v4] lib/bpf: Rename bpf function names to avoid potential conflict with libpcap To: Konstantin Ananyev Cc: dev@dpdk.org, stephen@networkplumber.org, thomas@monjalon.net, Ruifeng Wang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org I've read the libbpf code again and I found some other functions with pure 'bpf_' prefix. Should we rename all the functions whose names start with pure 'bpf_'? Konstantin Ananyev =E4=BA=8E2023=E5=B9=B43= =E6=9C=8812=E6=97=A5=E5=91=A8=E6=97=A5 22:02=E5=86=99=E9=81=93=EF=BC=9A > > 12/03/2023 06:20, J.J. Martzki =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > The library libpcap has their function 'bpf_validate' either so there w= ould > > be a multiple definition issue when linking with librte_bpf.a and libpc= ap.a > > statically (Same as http://dpdk.org/patch/52631). So just rename the > > function names to avoid such issue. > > > > Signed-off-by: J.J. Martzki > > > > --- > > v4: > > * Update my name. > > v3: > > * Rewrite the commit message. > > v2: > > * Rename all functions in bpf_impl.h. > > * Adjust the commit message. > > --- > > lib/bpf/bpf.c | 6 +++--- > > lib/bpf/bpf_convert.c | 3 --- > > lib/bpf/bpf_impl.h | 10 ++++------ > > lib/bpf/bpf_jit_arm64.c | 2 +- > > lib/bpf/bpf_jit_x86.c | 2 +- > > lib/bpf/bpf_load.c | 4 ++-- > > lib/bpf/bpf_validate.c | 2 +- > > 7 files changed, 12 insertions(+), 17 deletions(-) > > > > diff --git a/lib/bpf/bpf.c b/lib/bpf/bpf.c > > index 1e1dd42a58..f218a8f2b0 100644 > > --- a/lib/bpf/bpf.c > > +++ b/lib/bpf/bpf.c > > @@ -31,14 +31,14 @@ rte_bpf_get_jit(const struct rte_bpf *bpf, struct r= te_bpf_jit *jit) > > } > > > > int > > -bpf_jit(struct rte_bpf *bpf) > > +rte_bpf_jit(struct rte_bpf *bpf) > > { > > int32_t rc; > > > > #if defined(RTE_ARCH_X86_64) > > - rc =3D bpf_jit_x86(bpf); > > + rc =3D rte_bpf_jit_x86(bpf); > > #elif defined(RTE_ARCH_ARM64) > > - rc =3D bpf_jit_arm64(bpf); > > + rc =3D rte_bpf_jit_arm64(bpf); > > #else > > rc =3D -ENOTSUP; > > #endif > > diff --git a/lib/bpf/bpf_convert.c b/lib/bpf/bpf_convert.c > > index 9563274c9c..d441be6663 100644 > > --- a/lib/bpf/bpf_convert.c > > +++ b/lib/bpf/bpf_convert.c > > @@ -23,11 +23,8 @@ > > #include > > #include > > > > -/* Workaround name conflicts with libpcap */ > > -#define bpf_validate(f, len) bpf_validate_libpcap(f, len) > > #include > > #include > > -#undef bpf_validate > > > > #include "bpf_impl.h" > > #include "bpf_def.h" > > diff --git a/lib/bpf/bpf_impl.h b/lib/bpf/bpf_impl.h > > index b4d8e87c6d..e955b74181 100644 > > --- a/lib/bpf/bpf_impl.h > > +++ b/lib/bpf/bpf_impl.h > > @@ -17,12 +17,10 @@ struct rte_bpf { > > uint32_t stack_sz; > > }; > > > > -extern int bpf_validate(struct rte_bpf *bpf); > > - > > -extern int bpf_jit(struct rte_bpf *bpf); > > - > > -extern int bpf_jit_x86(struct rte_bpf *); > > -extern int bpf_jit_arm64(struct rte_bpf *); > > +extern int rte_bpf_validate(struct rte_bpf *bpf); > > +extern int rte_bpf_jit(struct rte_bpf *bpf); > > +extern int rte_bpf_jit_x86(struct rte_bpf *bpf); > > +extern int rte_bpf_jit_arm64(struct rte_bpf *bpf); > > I am still not quite ok to us 'rte_' prefix for internal library > functions... > Might be at least '_rte_', or '_bpf_'? > Another ask - can you put comment here with advise for future > add-ons to avoid pure 'bpf_' prefix and why. > Konstantin > > > > extern int rte_bpf_logtype; > > > > diff --git a/lib/bpf/bpf_jit_arm64.c b/lib/bpf/bpf_jit_arm64.c > > index db79ff7385..d1ab5f8fbf 100644 > > --- a/lib/bpf/bpf_jit_arm64.c > > +++ b/lib/bpf/bpf_jit_arm64.c > > @@ -1393,7 +1393,7 @@ emit(struct a64_jit_ctx *ctx, struct rte_bpf *bpf= ) > > * Produce a native ISA version of the given BPF code. > > */ > > int > > -bpf_jit_arm64(struct rte_bpf *bpf) > > +rte_bpf_jit_arm64(struct rte_bpf *bpf) > > { > > struct a64_jit_ctx ctx; > > size_t size; > > diff --git a/lib/bpf/bpf_jit_x86.c b/lib/bpf/bpf_jit_x86.c > > index c1a30e0386..182004ac7d 100644 > > --- a/lib/bpf/bpf_jit_x86.c > > +++ b/lib/bpf/bpf_jit_x86.c > > @@ -1490,7 +1490,7 @@ emit(struct bpf_jit_state *st, const struct rte_b= pf *bpf) > > * produce a native ISA version of the given BPF code. > > */ > > int > > -bpf_jit_x86(struct rte_bpf *bpf) > > +rte_bpf_jit_x86(struct rte_bpf *bpf) > > { > > int32_t rc; > > uint32_t i; > > diff --git a/lib/bpf/bpf_load.c b/lib/bpf/bpf_load.c > > index 1e17df6ce0..2c4bca3586 100644 > > --- a/lib/bpf/bpf_load.c > > +++ b/lib/bpf/bpf_load.c > > @@ -108,9 +108,9 @@ rte_bpf_load(const struct rte_bpf_prm *prm) > > return NULL; > > } > > > > - rc =3D bpf_validate(bpf); > > + rc =3D rte_bpf_validate(bpf); > > if (rc =3D=3D 0) { > > - bpf_jit(bpf); > > + rte_bpf_jit(bpf); > > if (mprotect(bpf, bpf->sz, PROT_READ) !=3D 0) > > rc =3D -ENOMEM; > > } > > diff --git a/lib/bpf/bpf_validate.c b/lib/bpf/bpf_validate.c > > index 61cbb42216..2d3d899966 100644 > > --- a/lib/bpf/bpf_validate.c > > +++ b/lib/bpf/bpf_validate.c > > @@ -2302,7 +2302,7 @@ evaluate(struct bpf_verifier *bvf) > > } > > > > int > > -bpf_validate(struct rte_bpf *bpf) > > +rte_bpf_validate(struct rte_bpf *bpf) > > { > > int32_t rc; > > struct bpf_verifier bvf; >