DPDK patches and discussions
 help / color / mirror / Atom feed
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

  parent reply	other threads:[~2019-05-13 10:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 17:14 Smoczynski, MarcinX
2019-05-10 17:14 ` Smoczynski, MarcinX
2019-05-10 18:17 ` Thomas Monjalon
2019-05-10 18:17   ` Thomas Monjalon
2019-05-10 18:23   ` Thomas Monjalon
2019-05-10 18:23     ` Thomas Monjalon
2019-05-13  9:51     ` Smoczynski, MarcinX
2019-05-13  9:51       ` Smoczynski, MarcinX
2019-05-13 10:25       ` Adrien Mazarguil [this message]
2019-05-13 10:25         ` Adrien Mazarguil
2019-05-13 10:49         ` Ananyev, Konstantin
2019-05-13 10:49           ` Ananyev, Konstantin
2019-05-13 13:14           ` Adrien Mazarguil
2019-05-13 13:14             ` Adrien Mazarguil
2019-05-13 16:24             ` Ananyev, Konstantin
2019-05-13 16:24               ` Ananyev, Konstantin
2019-05-14  8:58               ` Smoczynski, MarcinX
2019-05-14  8:58                 ` Smoczynski, MarcinX
2019-05-14  9:16                 ` Adrien Mazarguil
2019-05-14  9:16                   ` Adrien Mazarguil
2019-05-14 10:29                   ` Ananyev, Konstantin
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).