[RFC,0/1] Specify C-standard requirement for DPDK builds

  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
  

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