Message ID | 20230112113556.47485-1-bruce.richardson@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0A324423B5; Thu, 12 Jan 2023 12:36:12 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C0F5042D22; Thu, 12 Jan 2023 12:36:11 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id CAD0740E25 for <dev@dpdk.org>; Thu, 12 Jan 2023 12:36:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673523370; x=1705059370; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=j6EJRx1rzP+vhIGrKHNYhAPgNZZ6MPoIjsRedrgbliw=; b=BgySlDITP0lMr9esQOg5o7CSpXxzPjUpf6GnsEUe7BWaVF6y++8Deyxz ysFhEVZayw4augqQagnqxWJsRz7/NvvLNY+akF+DPwtBmQS0A2BvQX/EE LEgd3TPvAr5mxFN3lobG5lzGS3e3AHYYfuvc/yLLbqmPq+5OmHr5iK6rA 2PjaASB5r6dX4lbdpfR58wdqpmz4MVrQqmgp88cfHJkHM+DEytjpiWsSd QGoy2ZunnpkjGsnDa23gGYuSic0mfvT6oW24JY5IhTjg2H9BzTXEqyaE/ JOx8fVQYNIvNwdjR9AauCudxkjGentJKYlTLK7tHTMDzQVLtRDP+BUKL3 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="323742516" X-IronPort-AV: E=Sophos;i="5.96,319,1665471600"; d="scan'208";a="323742516" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2023 03:36:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="690102017" X-IronPort-AV: E=Sophos;i="5.96,319,1665471600"; d="scan'208";a="690102017" Received: from silpixa00401385.ir.intel.com ([10.237.214.166]) by orsmga001.jf.intel.com with ESMTP; 12 Jan 2023 03:36:07 -0800 From: Bruce Richardson <bruce.richardson@intel.com> To: dev@dpdk.org Cc: thomas@monjalon.net, david.marchand@redhat.com, mb@smartsharesystems.com, roretzla@linux.microsoft.com, Bruce Richardson <bruce.richardson@intel.com> Subject: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds Date: Thu, 12 Jan 2023 11:35:55 +0000 Message-Id: <20230112113556.47485-1-bruce.richardson@intel.com> X-Mailer: git-send-email 2.37.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 |
Series |
Specify C-standard requirement for DPDK builds
|
|
Message
Bruce Richardson
Jan. 12, 2023, 11:35 a.m. UTC
Traditionally, DPDK has never specified a minimum C standard used either in DPDK builds or for applications using DPDK. Following discussion on-list about C standards, this RFC attempts to start the process of codifying what our standards expectations are. No code changes are made by this RFC, instead only the build parameters are changed to explicitly specify: * C99 standard is used to build DPDK itself. This is supported by all supported compiler versions of GCC and Clang. * The headers are checked for compatibility with gcc89 standard, which was the default standard used by the oldest supported version of GCC. DPDK headers do not build with the official C89 standard, and, to the best of my knowledge, have never done so. Bruce Richardson (1): build: increase minimum C standard for DPDK builds buildtools/chkincs/meson.build | 1 + meson.build | 1 + 2 files changed, 2 insertions(+) -- 2.37.2
Comments
Since this topic keeps coming up in other threads I'll chime in with my $0.01 here. We've been using CentOS 7 for awhile (and working on migrating off) but have had to leverage devtoolset/llvmtoolset for various reasons. I remember a discussion of installing a different compiler coming up but don't remember which thread that was in/what the outcome was. While I'd like to just brush over C7 and say there is a compatible compiler available so just make the change I also realize that making that change could be quite disruptive to existing code bases. However, the 22.11 LTS will be EOL in Nov 2024. CentOS 7 is EOL Jun 2024. For the 23.x series and going forward I don't think starting with a C11 requirement is an unreasonable ask. On Thu, Jan 12, 2023 at 6:36 AM Bruce Richardson <bruce.richardson@intel.com> wrote: > Traditionally, DPDK has never specified a minimum C standard used either > in DPDK builds or for applications using DPDK. Following discussion > on-list about C standards, this RFC attempts to start the process of > codifying what our standards expectations are. No code changes are made > by this RFC, instead only the build parameters are changed to explicitly > specify: > > * C99 standard is used to build DPDK itself. This is supported by all > supported compiler versions of GCC and Clang. > * The headers are checked for compatibility with gcc89 standard, which > was the default standard used by the oldest supported version of GCC. > DPDK headers do not build with the official C89 standard, and, to the > best of my knowledge, have never done so. > > Bruce Richardson (1): > build: increase minimum C standard for DPDK builds > > buildtools/chkincs/meson.build | 1 + > meson.build | 1 + > 2 files changed, 2 insertions(+) > > -- > 2.37.2 > >
On Fri, Feb 03, 2023 at 09:09:14AM -0500, Ben Magistro wrote: > Since this topic keeps coming up in other threads I'll chime in with my > $0.01 here. We've been using CentOS 7 for awhile (and working on > migrating off) but have had to leverage devtoolset/llvmtoolset for > various reasons. I remember a discussion of installing a different > compiler coming up but don't remember which thread that was in/what the > outcome was. While I'd like to just brush over C7 and say there is a > compatible compiler available so just make the change I also realize > that making that change could be quite disruptive to existing code > bases. > However, the 22.11 LTS will be EOL in Nov 2024. CentOS 7 is EOL Jun > 2024. For the 23.x series and going forward I don't think starting > with a C11 requirement is an unreasonable ask. > Thanks for that input. If we drop support for Centos/RHEL 7, I think we should be ok to pass -std=c11 for the build of DPDK. Have you any thoughts on the second part of the c11 move - where our headers require c11 support and therefore may require that the end user builds their own code using -std=c11? This latter part is the bit that concerns me a little, as I feel it may be problematic for some with older codebases. /Bruce
In our case we have other libraries that we are using that have required us to specify a minimum c++ version (14/17 most recently for one) so it doesn't feel like a big ask/issue to us (provided things don't start conflicting...hah; not anticipating any issue). Our software is also used internally so we have a fair bit of control over how fast we can adopt changes. This got me wondering what some other projects in the DPDK ecosystem are saying/doing around language standards/gcc versions. So some quick checking of the projects I am aware of/looked at/using... * trex: cannot find an obvious minimum gcc requirement * tldk: we are running our own public folk with several fixes, need to find time to solve the build sys change aspect to continue providing patches upstream; I know I have hit some places where it was easier to say the new minimum DPDK version is x at which point you just adopt the minimum requirements of DPDK * ovs: looks to be comfortable with an older gcc still * seastar: seems to be the most aggressive with adopting language standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+ * ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and is the same on the main README file I do understand the concern, but if no one is voicing an opinion/objection does that mean they agree with/will not be affected by the change.... 1) https://docs.seastar.io/master/md_compatibility.html 2) https://github.com/ansyun/dpdk-ans/releases Cheers On Fri, Feb 3, 2023 at 10:09 AM Bruce Richardson <bruce.richardson@intel.com> wrote: > On Fri, Feb 03, 2023 at 09:09:14AM -0500, Ben Magistro wrote: > > Since this topic keeps coming up in other threads I'll chime in with > my > > $0.01 here. We've been using CentOS 7 for awhile (and working on > > migrating off) but have had to leverage devtoolset/llvmtoolset for > > various reasons. I remember a discussion of installing a different > > compiler coming up but don't remember which thread that was in/what > the > > outcome was. While I'd like to just brush over C7 and say there is a > > compatible compiler available so just make the change I also realize > > that making that change could be quite disruptive to existing code > > bases. > > However, the 22.11 LTS will be EOL in Nov 2024. CentOS 7 is EOL Jun > > 2024. For the 23.x series and going forward I don't think starting > > with a C11 requirement is an unreasonable ask. > > > Thanks for that input. If we drop support for Centos/RHEL 7, I think we > should be ok to pass -std=c11 for the build of DPDK. > > Have you any thoughts on the second part of the c11 move - where our > headers require c11 support and therefore may require that the end user > builds their own code using -std=c11? This latter part is the bit that > concerns me a little, as I feel it may be problematic for some with older > codebases. > > /Bruce >
On Fri, Feb 03, 2023 at 11:45:04AM -0500, Ben Magistro wrote: > In our case we have other libraries that we are using that have > required us to specify a minimum c++ version (14/17 most recently for > one) so it doesn't feel like a big ask/issue to us (provided things > don't start conflicting...hah; not anticipating any issue). Our > software is also used internally so we have a fair bit of control over > how fast we can adopt changes. > This got me wondering what some other projects in the DPDK ecosystem > are saying/doing around language standards/gcc versions. So some quick > checking of the projects I am aware of/looked at/using... > * trex: cannot find an obvious minimum gcc requirement > * tldk: we are running our own public folk with several fixes, need to > find time to solve the build sys change aspect to continue providing > patches upstream; I know I have hit some places where it was easier to > say the new minimum DPDK version is x at which point you just adopt the > minimum requirements of DPDK > * ovs: looks to be comfortable with an older gcc still > * seastar: seems to be the most aggressive with adopting language > standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+ > * ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and is > the same on the main README file > I do understand the concern, but if no one is voicing an > opinion/objection does that mean they agree with/will not be affected > by the change.... > 1) [1]https://docs.seastar.io/master/md_compatibility.html > 2) [2]https://github.com/ansyun/dpdk-ans/releases > Cheers > Thanks for the info. I also notice that since gcc 5, the default language version used - if none is explicitly specified - is gnu11 (or higher for later versions). Clang seems to do something similar, but not sure at what point it started defaulting to a standard >=c11. /Bruce
Adding Tyler Sort of following along on the RFC: introduce atomics [1] it seems like the decision to use 99 vs 11 here could make an impact on the approach taken in that thread. 1) http://mails.dpdk.org/archives/dev/2023-February/262042.html On Fri, Feb 3, 2023 at 1:00 PM Bruce Richardson <bruce.richardson@intel.com> wrote: > On Fri, Feb 03, 2023 at 11:45:04AM -0500, Ben Magistro wrote: > > In our case we have other libraries that we are using that have > > required us to specify a minimum c++ version (14/17 most recently for > > one) so it doesn't feel like a big ask/issue to us (provided things > > don't start conflicting...hah; not anticipating any issue). Our > > software is also used internally so we have a fair bit of control over > > how fast we can adopt changes. > > This got me wondering what some other projects in the DPDK ecosystem > > are saying/doing around language standards/gcc versions. So some > quick > > checking of the projects I am aware of/looked at/using... > > * trex: cannot find an obvious minimum gcc requirement > > * tldk: we are running our own public folk with several fixes, need to > > find time to solve the build sys change aspect to continue providing > > patches upstream; I know I have hit some places where it was easier to > > say the new minimum DPDK version is x at which point you just adopt > the > > minimum requirements of DPDK > > * ovs: looks to be comfortable with an older gcc still > > * seastar: seems to be the most aggressive with adopting language > > standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+ > > * ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and > is > > the same on the main README file > > I do understand the concern, but if no one is voicing an > > opinion/objection does that mean they agree with/will not be affected > > by the change.... > > 1) [1]https://docs.seastar.io/master/md_compatibility.html > > 2) [2]https://github.com/ansyun/dpdk-ans/releases > > Cheers > > > Thanks for the info. > I also notice that since gcc 5, the default language version used - if none > is explicitly specified - is gnu11 (or higher for later versions). Clang > seems to do something similar, but not sure at what point it started > defaulting to a standard >=c11. > > /Bruce >
On Fri, Feb 10, 2023 at 09:52:06AM -0500, Ben Magistro wrote: > Adding Tyler > > Sort of following along on the RFC: introduce atomics [1] it seems like the > decision to use 99 vs 11 here could make an impact on the approach taken in > that thread. hey Ben thanks for keeping an eye across threads on the topic. the atomics thread is fairly long but somewhere in it i did provide a rationale for why we can't just go straight to using C11 even if we declared that dpdk on supports compilers >= C11. i wish we could it would certainly make my life way easier if i could just -std=c11 and cut & paste my way to completion. the reason why we can't (aside from not requiring C11 compiler as a minimum) is that there is potential issue with abi compatibility for existing applications using non-atomic types currently passed to ABI suddenly requiring standard atomic types. this is because _Atomic type and type are not guaranteed to have the same size, alignment, representation etc.. anyway, i welcome us establishing c99 as a minimum for all toolchain/platform combinations. > > 1) http://mails.dpdk.org/archives/dev/2023-February/262042.html > > On Fri, Feb 3, 2023 at 1:00 PM Bruce Richardson <bruce.richardson@intel.com> > wrote: > > > On Fri, Feb 03, 2023 at 11:45:04AM -0500, Ben Magistro wrote: > > > In our case we have other libraries that we are using that have > > > required us to specify a minimum c++ version (14/17 most recently for > > > one) so it doesn't feel like a big ask/issue to us (provided things > > > don't start conflicting...hah; not anticipating any issue). Our > > > software is also used internally so we have a fair bit of control over > > > how fast we can adopt changes. > > > This got me wondering what some other projects in the DPDK ecosystem > > > are saying/doing around language standards/gcc versions. So some > > quick > > > checking of the projects I am aware of/looked at/using... > > > * trex: cannot find an obvious minimum gcc requirement > > > * tldk: we are running our own public folk with several fixes, need to > > > find time to solve the build sys change aspect to continue providing > > > patches upstream; I know I have hit some places where it was easier to > > > say the new minimum DPDK version is x at which point you just adopt > > the > > > minimum requirements of DPDK > > > * ovs: looks to be comfortable with an older gcc still > > > * seastar: seems to be the most aggressive with adopting language > > > standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+ > > > * ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and > > is > > > the same on the main README file > > > I do understand the concern, but if no one is voicing an > > > opinion/objection does that mean they agree with/will not be affected > > > by the change.... > > > 1) [1]https://docs.seastar.io/master/md_compatibility.html > > > 2) [2]https://github.com/ansyun/dpdk-ans/releases > > > Cheers > > > > > Thanks for the info. > > I also notice that since gcc 5, the default language version used - if none > > is explicitly specified - is gnu11 (or higher for later versions). Clang > > seems to do something similar, but not sure at what point it started > > defaulting to a standard >=c11. > > > > /Bruce > >
On Thu, Jan 12, 2023 at 11:35:55AM +0000, Bruce Richardson wrote: > Traditionally, DPDK has never specified a minimum C standard used either > in DPDK builds or for applications using DPDK. Following discussion > on-list about C standards, this RFC attempts to start the process of > codifying what our standards expectations are. No code changes are made > by this RFC, instead only the build parameters are changed to explicitly > specify: > > * C99 standard is used to build DPDK itself. This is supported by all > supported compiler versions of GCC and Clang. > * The headers are checked for compatibility with gcc89 standard, which > was the default standard used by the oldest supported version of GCC. > DPDK headers do not build with the official C89 standard, and, to the > best of my knowledge, have never done so. subject to the technical board meeting 2023/02/22 in relation to atomics and adoption of C11 starting in 23.11 does anything stop us from conditionally enabling/defaulting -std=C11 for all platforms immediately except for RHEL/CentOS 7? so long as we don't actually start using C11 features we should be able to do this? or would we be worried that C11 feature use would creep in? just curious. > > Bruce Richardson (1): > build: increase minimum C standard for DPDK builds > > buildtools/chkincs/meson.build | 1 + > meson.build | 1 + > 2 files changed, 2 insertions(+) > > -- > 2.37.2
On Wed, Feb 22, 2023 at 10:53:44AM -0800, Tyler Retzlaff wrote: > On Thu, Jan 12, 2023 at 11:35:55AM +0000, Bruce Richardson wrote: > > Traditionally, DPDK has never specified a minimum C standard used either > > in DPDK builds or for applications using DPDK. Following discussion > > on-list about C standards, this RFC attempts to start the process of > > codifying what our standards expectations are. No code changes are made > > by this RFC, instead only the build parameters are changed to explicitly > > specify: > > > > * C99 standard is used to build DPDK itself. This is supported by all > > supported compiler versions of GCC and Clang. > > * The headers are checked for compatibility with gcc89 standard, which > > was the default standard used by the oldest supported version of GCC. > > DPDK headers do not build with the official C89 standard, and, to the > > best of my knowledge, have never done so. > > subject to the technical board meeting 2023/02/22 in relation to atomics > and adoption of C11 starting in 23.11 does anything stop us from > conditionally enabling/defaulting -std=C11 for all platforms immediately > except for RHEL/CentOS 7? > > so long as we don't actually start using C11 features we should be able > to do this? or would we be worried that C11 feature use would creep in? > > just curious. > Actually, if we don't do anything, the versions of gcc (and clang AFAIK) already default to C11 or later from GCC 5 onwards. If we were to specify a version, I think it would have to be gnu11 as we may still be using some GCC extensions. However, feel free to do up a patch for c11 if it works. The change to the header checks probably don't need to be included, only a change to the default options in the top-level meson.build file. Incidentally, even though it is missing support for the c11 atomics, gcc 4.8.5 on RHEL 7 does have the -std=c11 flag that can be used, so adding that shouldn't break anything. /Bruce