From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id EF14E293B for ; Mon, 13 May 2019 12:25:12 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id d12so14568455wrm.8 for ; Mon, 13 May 2019 03:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UmEeeiBJje6GCJUGuhaLC+ZVKxMgdtwa+WxfxExWAuk=; b=Ie5R+Cy3Ael1uSAff0loxFDds/iwruC8HNX4SoQoamdAO/Rk3w/sZ9yplFLTiHR09B OAzLH94dqlCWwDhgar8kMQYLAaRkkafsxLS87nw7PVlnCqSsGnlP5LSLVTOuPDCYgGuH yXXTWQwV6Hfq6TzZDSrCXD6h5Rkbx1Z6n2auQtv0MYuvUTM6AYB3JXixOlZNWNhHhpZu pbXsFdtbUcpomxNb1MnC3nxp63i0tcZ1ctatAtiJuYF+pyxBCE0oQjwBR0EsK6VlKNhE rCMpuD4cspSNZiazeir7yDQt09Ei/3CyhJ0mCW0LMuH4yVQ8Mgt2dt7asw2sBxg+vKlo TgbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UmEeeiBJje6GCJUGuhaLC+ZVKxMgdtwa+WxfxExWAuk=; b=ud1MOwnR2zFX87KVjtWuUTkH5qQv1r8MXcmwS+gKimKY+rryK1aKx+rmEncPwQ+LQQ syqWJnNSWCPyETwYSJ+DcvaQwl1pajL5+UR3Yem0l0rLuiPCHRmjq9t4YWY3xhP9A7w0 63NuSW5g4sDbuwfB2tRZbqGCP2mYsnuDMve3eWbVxb5MNkaAtXqoMQ3bK44fpUjBYXvg 9jh/+O7pE1+FutPyUtLWj3Yr9db7RK9mZ/Nr0p1DVdy6juYy/jBil9WNfcI6HtTsWT2h ZGUnLYgEvOdQ+O6RKsjyeGoCk6mpME9AOi40xgy+MYPT+wNumUbe94hZ7SnP8M9Izl3E NfAg== X-Gm-Message-State: APjAAAVot5JxPiiZtp76nqy74cs/BKcbCtWAmUeXsoxUdT7uhTiOJBbc 1nO9mOlRBddC79kzhTV0NspcIA== X-Google-Smtp-Source: APXvYqypumg+C7aT/m3fUJoWzOrz4rAani/TZpwMSQABoZ4XQTrgzvqpMePuzQrs2ATrRPaTaZU+6g== X-Received: by 2002:a05:6000:1203:: with SMTP id e3mr17202878wrx.300.1557743112757; Mon, 13 May 2019 03:25:12 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id b12sm2151089wmg.27.2019.05.13.03.25.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 03:25:11 -0700 (PDT) Date: Mon, 13 May 2019 12:25:10 +0200 From: Adrien Mazarguil To: "Smoczynski, MarcinX" Cc: Thomas Monjalon , "dev@dpdk.org" , "Richardson, Bruce" , "Ananyev, Konstantin" , "shahafs@mellanox.com" , "gaetan.rivet@6wind.com" , "matan@mellanox.com" Message-ID: <20190513102510.GJ4284@6wind.com> References: <2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com> <9076832.UKkv39EgZr@xps> <2604468.nBFxeWxGDx@xps> <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 10:25:14 -0000 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id CFDCCA00E6 for ; Mon, 13 May 2019 12:25:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 997C03253; Mon, 13 May 2019 12:25:15 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id EF14E293B for ; Mon, 13 May 2019 12:25:12 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id d12so14568455wrm.8 for ; Mon, 13 May 2019 03:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UmEeeiBJje6GCJUGuhaLC+ZVKxMgdtwa+WxfxExWAuk=; b=Ie5R+Cy3Ael1uSAff0loxFDds/iwruC8HNX4SoQoamdAO/Rk3w/sZ9yplFLTiHR09B OAzLH94dqlCWwDhgar8kMQYLAaRkkafsxLS87nw7PVlnCqSsGnlP5LSLVTOuPDCYgGuH yXXTWQwV6Hfq6TzZDSrCXD6h5Rkbx1Z6n2auQtv0MYuvUTM6AYB3JXixOlZNWNhHhpZu pbXsFdtbUcpomxNb1MnC3nxp63i0tcZ1ctatAtiJuYF+pyxBCE0oQjwBR0EsK6VlKNhE rCMpuD4cspSNZiazeir7yDQt09Ei/3CyhJ0mCW0LMuH4yVQ8Mgt2dt7asw2sBxg+vKlo TgbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UmEeeiBJje6GCJUGuhaLC+ZVKxMgdtwa+WxfxExWAuk=; b=ud1MOwnR2zFX87KVjtWuUTkH5qQv1r8MXcmwS+gKimKY+rryK1aKx+rmEncPwQ+LQQ syqWJnNSWCPyETwYSJ+DcvaQwl1pajL5+UR3Yem0l0rLuiPCHRmjq9t4YWY3xhP9A7w0 63NuSW5g4sDbuwfB2tRZbqGCP2mYsnuDMve3eWbVxb5MNkaAtXqoMQ3bK44fpUjBYXvg 9jh/+O7pE1+FutPyUtLWj3Yr9db7RK9mZ/Nr0p1DVdy6juYy/jBil9WNfcI6HtTsWT2h ZGUnLYgEvOdQ+O6RKsjyeGoCk6mpME9AOi40xgy+MYPT+wNumUbe94hZ7SnP8M9Izl3E NfAg== X-Gm-Message-State: APjAAAVot5JxPiiZtp76nqy74cs/BKcbCtWAmUeXsoxUdT7uhTiOJBbc 1nO9mOlRBddC79kzhTV0NspcIA== X-Google-Smtp-Source: APXvYqypumg+C7aT/m3fUJoWzOrz4rAani/TZpwMSQABoZ4XQTrgzvqpMePuzQrs2ATrRPaTaZU+6g== X-Received: by 2002:a05:6000:1203:: with SMTP id e3mr17202878wrx.300.1557743112757; Mon, 13 May 2019 03:25:12 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id b12sm2151089wmg.27.2019.05.13.03.25.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 03:25:11 -0700 (PDT) Date: Mon, 13 May 2019 12:25:10 +0200 From: Adrien Mazarguil To: "Smoczynski, MarcinX" Cc: Thomas Monjalon , "dev@dpdk.org" , "Richardson, Bruce" , "Ananyev, Konstantin" , "shahafs@mellanox.com" , "gaetan.rivet@6wind.com" , "matan@mellanox.com" Message-ID: <20190513102510.GJ4284@6wind.com> References: <2F25558C1648FA498380EAC12A8612624FD953@HASMSX110.ger.corp.intel.com> <9076832.UKkv39EgZr@xps> <2604468.nBFxeWxGDx@xps> <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <2F25558C1648FA498380EAC12A86126251F3B2@HASMSX110.ger.corp.intel.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190513102510.vqJj0rfZ5AuwPbGnRTyhkxCeRVvP3iz-9U-sCuYivXs@z> 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