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 2955141DCC; Mon, 13 Mar 2023 02:49:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A2041406BC; Mon, 13 Mar 2023 02:49:37 +0100 (CET) Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by mails.dpdk.org (Postfix) with ESMTP id 5819740151 for ; Mon, 13 Mar 2023 02:49:36 +0100 (CET) Received: by mail-pj1-f50.google.com with SMTP id fy10-20020a17090b020a00b0023b4bcf0727so2663315pjb.0 for ; Sun, 12 Mar 2023 18:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678672175; 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=SJtWcJ+AThGDkJsyyFGm0HyhOrTJ/eXOaIlBlcNKCNY=; b=S1BglRPjvaMTNzKTwtouEa42iko8ajPCnEEqC8wRsA3dq/FOiyIUx9LRfVlREPoJ64 G2F8rpkJLa0Kj31UwAOAtvpGknaKjoRThlDbAou9wpx5vUd1CzhhQuwSpx5IE3sMnqSz 7n9jTVysiV1HqmGwQjwLEsp6fnjoV+OXt/WeSGAXx8b/pXy4z3sz3DttDOUOXh2t592h QPiybF/5QdrfQf3DJRIwbX1fVPOiYtWKQiXbQ5jCvPGVAfQfXCfe/koxcJ3dc6Lp3uIC GMt1XVkpOOXZYIR8wPhERT/8hsI6DFwriBBHyCssKQq3Rmn6KFv0aEFcuG97ti2K4Lse VPFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678672175; 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=SJtWcJ+AThGDkJsyyFGm0HyhOrTJ/eXOaIlBlcNKCNY=; b=eG7O++AgHWr3LMDnjruMaiYy149yEx6f9yKnku82Ul4izkQ6rK0HqOmA15H4mDYjJ7 5+BuHJqeB+RkbcmDVSME47WgSMrQmK6gnhK5cS13bIkykPej+q2uhG5m0ubLcvVisWhB RBIlmo2mRgwKG5CyolsARPXL8dII3BPjb7/2kujskX4c/SRuVA1d9CRCGXpG/koZzNYm iuP6btoaaSl+beSK/Eiyx3ODCB+1Ie0oxfvCz8yziwCd/gc6JPKENiR6XC3pNRgYFy0r ggEcmIGxLglXBRAw9/kj57DXVa35Vj0pIlRWgx3qxBwciwzk/nW0nxz7KmH64Ickzbuc GuDw== X-Gm-Message-State: AO0yUKU/zWjD5biXca8Tizl0bmJPEIk1apZ4kawJcqcAt+jNRkE/WV0t 9GHFli1X0u6s9hSwQDloJ2+wHBIlqtTt7WxiPLrD+9NsTsvSZVtt X-Google-Smtp-Source: AK7set9ZXcCmxdpHnRoewBvlbVd3e27DEnUqM77id5WT2Qkb3CU7cf4HRwGZUNN6g8iFqDRcJfuVT9YshUtAqQSZIQ8= X-Received: by 2002:a17:903:280f:b0:19e:f660:81ee with SMTP id kp15-20020a170903280f00b0019ef66081eemr5962932plb.2.1678672175301; Sun, 12 Mar 2023 18:49:35 -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. Mars" Date: Mon, 13 Mar 2023 09:50:15 +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 Actually I'm still hesitating about the 'rte_' prefix either. So I'll try a new prefix in the next version, comments will be added together :) 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; >