From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <marcinx.smoczynski@intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id AD89E4CC3
 for <dev@dpdk.org>; Tue, 14 May 2019 10:58:47 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
 by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 14 May 2019 01:58:46 -0700
X-ExtLoop1: 1
Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205])
 by fmsmga005.fm.intel.com with ESMTP; 14 May 2019 01:58:46 -0700
Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by
 fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS)
 id 14.3.408.0; Tue, 14 May 2019 01:58:46 -0700
Received: from lcsmsx155.ger.corp.intel.com (10.186.165.233) by
 FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS)
 id 14.3.408.0; Tue, 14 May 2019 01:58:45 -0700
Received: from HASMSX110.ger.corp.intel.com ([169.254.6.92]) by
 LCSMSX155.ger.corp.intel.com ([169.254.12.172]) with mapi id 14.03.0415.000;
 Tue, 14 May 2019 11:58:43 +0300
From: "Smoczynski, MarcinX" <marcinx.smoczynski@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Adrien Mazarguil
 <adrien.mazarguil@6wind.com>
CC: Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>,
 "Richardson, Bruce" <bruce.richardson@intel.com>, "shahafs@mellanox.com"
 <shahafs@mellanox.com>, "gaetan.rivet@6wind.com" <gaetan.rivet@6wind.com>,
 "matan@mellanox.com" <matan@mellanox.com>
Thread-Topic: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD
Thread-Index: AdUHUhFuf1vcUQd1TgeecdbKRnBo9f//4sQAgAAB2gD/+6jjcIAIiFoAgAAGqQCAACi1AIAANQaA//67E1A=
Date: Tue, 14 May 2019 08:58:42 +0000
Message-ID: <2F25558C1648FA498380EAC12A86126251FDD5@HASMSX110.ger.corp.intel.com>
References: <2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com>
 <9076832.UKkv39EgZr@xps> <2604468.nBFxeWxGDx@xps>
 <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com>
 <20190513102510.GJ4284@6wind.com>
 <2601191342CEEE43887BDE71AB9772580161631159@irsmsx105.ger.corp.intel.com>
 <20190513131442.GK4284@6wind.com>
 <2601191342CEEE43887BDE71AB97725801616313F3@irsmsx105.ger.corp.intel.com>
In-Reply-To: <2601191342CEEE43887BDE71AB97725801616313F3@irsmsx105.ger.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.0.600.7
dlp-reaction: no-action
x-ctpclassification: CTP_NT
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2YwMDRlZjUtZTk2Ny00NDZmLWEzY2QtMmMyMzBjOTMyZWE5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTXpvbUZjYSs2RWI2dFZHbmF6eHR6d1lIVkRwZmJVM0hoTnlNQmViVnN0QVBaTTNVRlk1MFpcL3kyZlVXWmZpNmwifQ==
x-originating-ip: [10.104.12.183]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on
 FreeBSD
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 14 May 2019 08:58:48 -0000

> > Hey Konstantin,
> >
> > On Mon, May 13, 2019 at 10:49:00AM +0000, Ananyev, Konstantin wrote:
> > > Hi Adrien,
> > >
> > > >
> > > > On Mon, May 13, 2019 at 09:51:24AM +0000, Smoczynski, MarcinX
> wrote:
> > > > > 10/05/2019 20:17, Thomas Monjalon:
> > > > > > 10/05/2019 19:14, Smoczynski, MarcinX:
> > > > > > > To summarize we have different visibility sets for Linux and
> > > > > > > BSD when using XOPEN_SOURCE or POSIX_C_SOURCE explicitly.
> To
> > > > > > > overcome this situation we can either remove problematic
> > > > > > > XOPEN macros from mk/meson rules (drivers/net/failsafe,
> > > > > > > drivers/net/mlx4,
> > > > > > > drivers/net/mlx5)
> > > > > >
> > > > > > What is the consequence of removing these macros in mlx and
> failsafe PMDs?
> > > > >
> > > > > The purpose of these *_SOURCE constants is to enable particular
> > > > > feature sets visibility. As long as we have GNU_SOURCE on Linux
> > > > > removing it won't have any consequences. On BSD it will unify
> > > > > feature sets visibility with the rest of sources. Can't think of =
any
> downsides here.
> > > > >
> > > > > I believe XOPEN_SOURCE was introduced to extend features not to
> restrict them.
> > > >
> > > > I confirm that under Linux, all IPPROTO_* (POSIX/XOPEN/RFC1700)
> > > > are defined regardless (_GNU_SOURCE not even needed), while under
> > > > FreeBSD, the non-POSIX versions are only defined when
> __BSD_VISIBLE is set.
> > > >
> > > > The FreeBSD behavior is more correct in this respect since the
> > > > purpose of _XOPEN_SOURCE and friends is also to let applications
> > > > limit the risk of redefinitions in case they were written for an
> > > > earlier standard (e.g. -D_XOPEN_SOURCE=3D500 vs. -
> D_XOPEN_SOURCE=3D600).
> > >
> > > Still not sure why do you need it for failsafe and mlx PMDs?
> > > Would something in these PMDs be broken without  '-
> D_XOPEN_SOURCE=3D600'?
> >
> > Well, not really. At least not anymore if they compile fine without it
> > on all supported targets. I don't mind if they are removed from PMDs.
> >
> > _XOPEN_SOURCE=3D600 was originally added to mlx4 (later inherited by
> > mlx5 and
> > failsafe) for the following reasons:
> >
> > - Out fo habit, since a lot of stuff in unistd.h and fcntl.h depends on=
 it
> >   to be exposed. Some affected definitions were likely needed at some
> point.
> >
> > - Besides toggling C syntax extensions, forcing a C standard through th=
e
> >   -std parameter (e.g. -std=3Dc99) in order to guarantee a minimum leve=
l of
> >   C compliance disables the implicit presence of nonstandard definition=
s,
> >   which must be re-enabled as needed through the appropriate #defines.
> >
> > For instance, including unistd.h for getsid() stops working as soon as
> > you use -std=3Dc99. On Linux you can get it back through -std=3Dgnu99 o=
r
> > by combining -std=3Dc99 with -D_GNU_SOURCE or -D_XOPEN_SOURCE. The
> > latter was chosen because it is the standard define supposed to work
> across OSes.
> >
> > Historically mlx4 had to enable -std=3Dc99 to be able to use various
> > features not present when GCC defaulted to -std=3Dgnu90. It was later
> > transformed to
> > -std=3Dc11 for similar reasons (anonymous members in structs/unions if
> > memory serves me right).
> >
> > > > DPDK applications may also define _XOPEN_SOURCE for their own
> > > > needs. They should still be able to use rte_ip.h afterward.
> > >
> > > I suppose they can, they would just have (on FreeBSD) to add '-D
> __BSD_VISIBLE'
> > > themselves.
> >
> > Of course, but public headers should be as self sufficient as possible.
> > Unless they provide really insane compiler flags, if user applications
> > get compilation errors after including some header we install on the
> > system, I think the blame is on DPDK.
> >
> > > > I think this reason is
> > > > enough to go with -D__BSD_VISIBLE under FreeBSD without removing
> > > > _XOPEN_SOURCE, as it should work regardless.
> > >
> > > So do you suggest to add '-D __BSD_VISIBLE'  into mlx/failsafe PMDs
> > > Makefiles/meson.build, or ... ?
> >
> > Since headers of our public API potentially require it, it must be
> > defined globally (unlike _XOPEN_SOURCE which is only local to a few
> PMDs):
> > app/meson.build, lib/meson.build, mk/target/generic/rte.vars.mk,
> > alongside -D_GNU_SOURCE.
> >
> > Add it to mlx*/failsafe only if that's not enough. Just make sure
> > applications inherit this flag.
>
> Ok, to summarize, eyour suggestion is:
> 1. remove -D_XOPEN_SOURCE=3D... from mlx and failsafe PMDs.
> 2. add '-D __BSD_VISIBLE'  into top level make/meson files
> (app/meson.build, lib/meson.build, mk/target/generic/rte.vars.mk) Similar
> to what we doing for -DGNU_SOURCE.
>
> If I understand you correctly, then it sounds ok to me.
>
> >
> > > > Looking at the patch [1], I also think there's another, simpler app=
roach:
> > > > unless really performance critical, defining
> > > > rte_ipv6_get_next_ext() in rte_net.c instead of a static inline in
> rte_ip.h should address this issue.
> > >
> > > It is performance critical, and I think that function call for each
> > > ext header is a way too expensive approach.
> > > Will prefer to keep that function inline.
> >
> > OK, a bit cumbersome but since we're heading this way [2], how about
> > defining our own instead of all the above?
> >
> >  #define RTE_IPPROTO_HOPOPTS 0
> >  #define RTE_IPPROTO_ROUTING 43
> >  ...
> >
> > Which could prove handy later as it appears Linux and FreeBSD don't
> > have the same set of available IPPROTO_* definitions.
> >
> > Thoughts?
> >
> > [2] "[RFC v2 00/14] prefix network structures"
> >     https://mails.dpdk.org/archives/dev/2019-April/129752.html
>
> Yep, that's definitely an option too.
> But if we going to replace all current references of IPPROTO_ inside DPDK=
 to
> RTE_IPROTO_ - the change will be massive.
> And for sure it is out of scope of this patch series.
> That's probably need to be done after Olivier RFC will be in and should b=
e
> subject of a separate patch series.
> Konstantin

I agree that we need RTE_IPPROTO* macros but as Konstantin pointed out this
would be a huge change and we should do that on top of Oliver's work in
a separate patch set.

I will propose a patch set with:
1. Removed XOPEN_SOURCE macros as they are not needed anymore
2. Added BSD_VISIBLE at the top of build system.

Thanks for your comments, Marcin.

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by dpdk.space (Postfix) with ESMTP id E110AA00E6
	for <public@inbox.dpdk.org>; Tue, 14 May 2019 10:58:50 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 026125688;
	Tue, 14 May 2019 10:58:50 +0200 (CEST)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id AD89E4CC3
 for <dev@dpdk.org>; Tue, 14 May 2019 10:58:47 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
 by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 14 May 2019 01:58:46 -0700
X-ExtLoop1: 1
Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205])
 by fmsmga005.fm.intel.com with ESMTP; 14 May 2019 01:58:46 -0700
Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by
 fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS)
 id 14.3.408.0; Tue, 14 May 2019 01:58:46 -0700
Received: from lcsmsx155.ger.corp.intel.com (10.186.165.233) by
 FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS)
 id 14.3.408.0; Tue, 14 May 2019 01:58:45 -0700
Received: from HASMSX110.ger.corp.intel.com ([169.254.6.92]) by
 LCSMSX155.ger.corp.intel.com ([169.254.12.172]) with mapi id 14.03.0415.000;
 Tue, 14 May 2019 11:58:43 +0300
From: "Smoczynski, MarcinX" <marcinx.smoczynski@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Adrien Mazarguil
 <adrien.mazarguil@6wind.com>
CC: Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>,
 "Richardson, Bruce" <bruce.richardson@intel.com>, "shahafs@mellanox.com"
 <shahafs@mellanox.com>, "gaetan.rivet@6wind.com" <gaetan.rivet@6wind.com>,
 "matan@mellanox.com" <matan@mellanox.com>
Thread-Topic: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD
Thread-Index: AdUHUhFuf1vcUQd1TgeecdbKRnBo9f//4sQAgAAB2gD/+6jjcIAIiFoAgAAGqQCAACi1AIAANQaA//67E1A=
Date: Tue, 14 May 2019 08:58:42 +0000
Message-ID:
 <2F25558C1648FA498380EAC12A86126251FDD5@HASMSX110.ger.corp.intel.com>
References: <2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com>
 <9076832.UKkv39EgZr@xps> <2604468.nBFxeWxGDx@xps>
 <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com>
 <20190513102510.GJ4284@6wind.com>
 <2601191342CEEE43887BDE71AB9772580161631159@irsmsx105.ger.corp.intel.com>
 <20190513131442.GK4284@6wind.com>
 <2601191342CEEE43887BDE71AB97725801616313F3@irsmsx105.ger.corp.intel.com>
In-Reply-To: <2601191342CEEE43887BDE71AB97725801616313F3@irsmsx105.ger.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.0.600.7
dlp-reaction: no-action
x-ctpclassification: CTP_NT
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2YwMDRlZjUtZTk2Ny00NDZmLWEzY2QtMmMyMzBjOTMyZWE5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTXpvbUZjYSs2RWI2dFZHbmF6eHR6d1lIVkRwZmJVM0hoTnlNQmViVnN0QVBaTTNVRlk1MFpcL3kyZlVXWmZpNmwifQ==
x-originating-ip: [10.104.12.183]
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on
 FreeBSD
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Message-ID: <20190514085842.Em2EwVFKJtbrmnmGUdiwvqu4DhVPyGES3WV8yV7v9uY@z>

> > Hey Konstantin,
> >
> > On Mon, May 13, 2019 at 10:49:00AM +0000, Ananyev, Konstantin wrote:
> > > Hi Adrien,
> > >
> > > >
> > > > On Mon, May 13, 2019 at 09:51:24AM +0000, Smoczynski, MarcinX
> wrote:
> > > > > 10/05/2019 20:17, Thomas Monjalon:
> > > > > > 10/05/2019 19:14, Smoczynski, MarcinX:
> > > > > > > To summarize we have different visibility sets for Linux and
> > > > > > > BSD when using XOPEN_SOURCE or POSIX_C_SOURCE explicitly.
> To
> > > > > > > overcome this situation we can either remove problematic
> > > > > > > XOPEN macros from mk/meson rules (drivers/net/failsafe,
> > > > > > > drivers/net/mlx4,
> > > > > > > drivers/net/mlx5)
> > > > > >
> > > > > > What is the consequence of removing these macros in mlx and
> failsafe PMDs?
> > > > >
> > > > > The purpose of these *_SOURCE constants is to enable particular
> > > > > feature sets visibility. As long as we have GNU_SOURCE on Linux
> > > > > removing it won't have any consequences. On BSD it will unify
> > > > > feature sets visibility with the rest of sources. Can't think of =
any
> downsides here.
> > > > >
> > > > > I believe XOPEN_SOURCE was introduced to extend features not to
> restrict them.
> > > >
> > > > I confirm that under Linux, all IPPROTO_* (POSIX/XOPEN/RFC1700)
> > > > are defined regardless (_GNU_SOURCE not even needed), while under
> > > > FreeBSD, the non-POSIX versions are only defined when
> __BSD_VISIBLE is set.
> > > >
> > > > The FreeBSD behavior is more correct in this respect since the
> > > > purpose of _XOPEN_SOURCE and friends is also to let applications
> > > > limit the risk of redefinitions in case they were written for an
> > > > earlier standard (e.g. -D_XOPEN_SOURCE=3D500 vs. -
> D_XOPEN_SOURCE=3D600).
> > >
> > > Still not sure why do you need it for failsafe and mlx PMDs?
> > > Would something in these PMDs be broken without  '-
> D_XOPEN_SOURCE=3D600'?
> >
> > Well, not really. At least not anymore if they compile fine without it
> > on all supported targets. I don't mind if they are removed from PMDs.
> >
> > _XOPEN_SOURCE=3D600 was originally added to mlx4 (later inherited by
> > mlx5 and
> > failsafe) for the following reasons:
> >
> > - Out fo habit, since a lot of stuff in unistd.h and fcntl.h depends on=
 it
> >   to be exposed. Some affected definitions were likely needed at some
> point.
> >
> > - Besides toggling C syntax extensions, forcing a C standard through th=
e
> >   -std parameter (e.g. -std=3Dc99) in order to guarantee a minimum leve=
l of
> >   C compliance disables the implicit presence of nonstandard definition=
s,
> >   which must be re-enabled as needed through the appropriate #defines.
> >
> > For instance, including unistd.h for getsid() stops working as soon as
> > you use -std=3Dc99. On Linux you can get it back through -std=3Dgnu99 o=
r
> > by combining -std=3Dc99 with -D_GNU_SOURCE or -D_XOPEN_SOURCE. The
> > latter was chosen because it is the standard define supposed to work
> across OSes.
> >
> > Historically mlx4 had to enable -std=3Dc99 to be able to use various
> > features not present when GCC defaulted to -std=3Dgnu90. It was later
> > transformed to
> > -std=3Dc11 for similar reasons (anonymous members in structs/unions if
> > memory serves me right).
> >
> > > > DPDK applications may also define _XOPEN_SOURCE for their own
> > > > needs. They should still be able to use rte_ip.h afterward.
> > >
> > > I suppose they can, they would just have (on FreeBSD) to add '-D
> __BSD_VISIBLE'
> > > themselves.
> >
> > Of course, but public headers should be as self sufficient as possible.
> > Unless they provide really insane compiler flags, if user applications
> > get compilation errors after including some header we install on the
> > system, I think the blame is on DPDK.
> >
> > > > I think this reason is
> > > > enough to go with -D__BSD_VISIBLE under FreeBSD without removing
> > > > _XOPEN_SOURCE, as it should work regardless.
> > >
> > > So do you suggest to add '-D __BSD_VISIBLE'  into mlx/failsafe PMDs
> > > Makefiles/meson.build, or ... ?
> >
> > Since headers of our public API potentially require it, it must be
> > defined globally (unlike _XOPEN_SOURCE which is only local to a few
> PMDs):
> > app/meson.build, lib/meson.build, mk/target/generic/rte.vars.mk,
> > alongside -D_GNU_SOURCE.
> >
> > Add it to mlx*/failsafe only if that's not enough. Just make sure
> > applications inherit this flag.
>
> Ok, to summarize, eyour suggestion is:
> 1. remove -D_XOPEN_SOURCE=3D... from mlx and failsafe PMDs.
> 2. add '-D __BSD_VISIBLE'  into top level make/meson files
> (app/meson.build, lib/meson.build, mk/target/generic/rte.vars.mk) Similar
> to what we doing for -DGNU_SOURCE.
>
> If I understand you correctly, then it sounds ok to me.
>
> >
> > > > Looking at the patch [1], I also think there's another, simpler app=
roach:
> > > > unless really performance critical, defining
> > > > rte_ipv6_get_next_ext() in rte_net.c instead of a static inline in
> rte_ip.h should address this issue.
> > >
> > > It is performance critical, and I think that function call for each
> > > ext header is a way too expensive approach.
> > > Will prefer to keep that function inline.
> >
> > OK, a bit cumbersome but since we're heading this way [2], how about
> > defining our own instead of all the above?
> >
> >  #define RTE_IPPROTO_HOPOPTS 0
> >  #define RTE_IPPROTO_ROUTING 43
> >  ...
> >
> > Which could prove handy later as it appears Linux and FreeBSD don't
> > have the same set of available IPPROTO_* definitions.
> >
> > Thoughts?
> >
> > [2] "[RFC v2 00/14] prefix network structures"
> >     https://mails.dpdk.org/archives/dev/2019-April/129752.html
>
> Yep, that's definitely an option too.
> But if we going to replace all current references of IPPROTO_ inside DPDK=
 to
> RTE_IPROTO_ - the change will be massive.
> And for sure it is out of scope of this patch series.
> That's probably need to be done after Olivier RFC will be in and should b=
e
> subject of a separate patch series.
> Konstantin

I agree that we need RTE_IPPROTO* macros but as Konstantin pointed out this
would be a huge change and we should do that on top of Oliver's work in
a separate patch set.

I will propose a patch set with:
1. Removed XOPEN_SOURCE macros as they are not needed anymore
2. Added BSD_VISIBLE at the top of build system.

Thanks for your comments, Marcin.