From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: "Smoczynski, MarcinX" <marcinx.smoczynski@intel.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
"dev@dpdk.org" <dev@dpdk.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"shahafs@mellanox.com" <shahafs@mellanox.com>,
"gaetan.rivet@6wind.com" <gaetan.rivet@6wind.com>,
"matan@mellanox.com" <matan@mellanox.com>
Subject: Re: [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD
Date: Mon, 13 May 2019 12:25:10 +0200 [thread overview]
Message-ID: <20190513102510.GJ4284@6wind.com> (raw)
In-Reply-To: <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com>
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=500 vs. -D_XOPEN_SOURCE=600).
DPDK applications may also define _XOPEN_SOURCE for their own needs. They
should still be able to use rte_ip.h afterward. I think this reason is
enough to go with -D__BSD_VISIBLE under FreeBSD without removing
_XOPEN_SOURCE, as it should work regardless.
Looking at the patch [1], I also think there's another, simpler approach:
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.
[1] "[PATCH 1/3] net: new ipv6 header extension parsing function"
https://mails.dpdk.org/archives/dev/2019-May/131885.html
--
Adrien Mazarguil
6WIND
next prev parent reply other threads:[~2019-05-13 10:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-10 17:14 [dpdk-dev] Using _XOPEN_SOURCE macros may break builds on FreeBSD Smoczynski, MarcinX
2019-05-10 18:17 ` Thomas Monjalon
2019-05-10 18:23 ` Thomas Monjalon
2019-05-13 9:51 ` Smoczynski, MarcinX
2019-05-13 10:25 ` Adrien Mazarguil [this message]
2019-05-13 10:49 ` Ananyev, Konstantin
2019-05-13 13:14 ` Adrien Mazarguil
2019-05-13 16:24 ` Ananyev, Konstantin
2019-05-14 8:58 ` Smoczynski, MarcinX
2019-05-14 9:16 ` Adrien Mazarguil
2019-05-14 10:29 ` Ananyev, Konstantin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190513102510.GJ4284@6wind.com \
--to=adrien.mazarguil@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=konstantin.ananyev@intel.com \
--cc=marcinx.smoczynski@intel.com \
--cc=matan@mellanox.com \
--cc=shahafs@mellanox.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.