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=500 vs. -D_XOPEN_SOURCE=600).
Still not sure why do you need it for failsafe and mlx PMDs? Would something in these PMDs be broken without '-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 suppose they can, they would just have (on FreeBSD) to add '-D __BSD_VISIBLE' themselves. > 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 ... ? > 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. 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. Konstantin
