RE: [PATCH v5] build: update DPDK to use C11 standard

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Friday, 11 August 2023 10.53
> 
> On Thu, Aug 10, 2023 at 03:34:43PM -0700, Tyler Retzlaff wrote:
> > On Thu, Aug 10, 2023 at 08:17:23PM +0200, Morten Brørup wrote:
> > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > > Sent: Thursday, 10 August 2023 19.03
> > > >
> > > > On Thu, 10 Aug 2023 18:49:09 +0200
> > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > >
> > > > > 10/08/2023 18:35, Bruce Richardson:
> > > > > > On Thu, Aug 10, 2023 at 07:48:39AM -0700, Stephen Hemminger
> wrote:
> > > > > > > On Thu, 10 Aug 2023 15:34:43 +0200
> > > > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > > >
> > > > > > > > 03/08/2023 15:36, David Marchand:
> > > > > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson
> > > > > > > > > <bruce.richardson@intel.com> wrote:
> > > > > > > > > >
> > > > > > > > > > As previously announced, DPDK 23.11 will require a C11
> > > > supporting
> > > > > > > > > > compiler and will use the C11 standard in all builds.
> > > > > > > > > >
> > > > > > > > > > Forcing use of the C standard, rather than the
> standard with
> > > > > > > > > > GNU extensions, means that some posix definitions
> which are
> > > > not in
> > > > > > > > > > the C standard are unavailable by default. We fix this
> by
> > > > ensuring
> > > > > > > > > > the correct defines or cflags are passed to the
> components
> > > > that
> > > > > > > > > > need them.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Bruce Richardson
> <bruce.richardson@intel.com>
> > > > > > > > > > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > > > > > Acked-by: Tyler Retzlaff
> <roretzla@linux.microsoft.com>
> > > > > > > > > Tested-by: Ali Alnubani <alialnu@nvidia.com>
> > > > > > > > >
> > > > > > > > > The CI results look good.
> > > > > > > > >
> > > > > > > > > Applied, thanks!
> > > > > > > >
> > > > > > > > The compiler support is updated, that's fine.
> > > > > > > > Should we go further and document some major Linux
> distributions?
> > > > > > > > One concern is to make clear RHEL 7 is not supported
> anymore.
> > > > > > > > Should it be a release note?
> > > > > > > >
> > > > > >
> > > > > > Well, DPDK currently is still building fine on Centos 7 for
> me, so
> > > > let's
> > > > > > hold off on claiming anything until it's definitely broken.
> > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Should be addressed in linux/sys_reqs.rst as well as
> deprecation
> > > > notice.
> > > > > > > Also, is it possible to add automated check in build for
> compiler
> > > > version?
> > > > > >
> > > > > > I'd be a little careful about what we claim, and I think
> current docs
> > > > are
> > > > > > accurate vs our original plans. What we didn't plan to support
> was
> > > > the GCC
> > > > > > and Clang compiler versions in RHEL 7, but if one installs an
> updated
> > > > GCC,
> > > > > > for example, the build should be fine on RHEL 7.
> > > > > >
> > > > > > Now, though, we are having to re-evaluate our use of
> stdatomics,
> > > > which
> > > > > > means we may not actually break RHEL 7 compatibility after
> all. We'll
> > > > have
> > > > > > to "watch this space" as the saying goes!
> > > > > >
> > > > > > Overall, I think the approach of build-time checks is the
> best, but
> > > > not
> > > > > > for specific versions, but instead for capabilities. If/when
> we add
> > > > support
> > > > > > for stdatomics to DPDK builds on Linux/BSD, at that point we
> put in
> > > > the
> > > > > > initial compiler checks a suitable check for them being
> present and
> > > > output
> > > > > > a suitable error if not found.
> > >
> > > Exactly. Capabilities checks is the right way to go when cross
> compiling.
> > >
> > > > >
> > > > > OK looks good
> > > >
> > > > Note: RHEL 7 official end of maintenance support is not until June
> 2024.
> > > >
> > >
> > > It was agreed to abandon RHEL 7, mainly driven by the need for C11
> stdatomic.h, which is not supported by the GCC C compiler included with
> RHEL 7. So it pains me to admit that Stephen has a valid point here,
> after it turned out that the GCC g++ is not C11 compatible.
> >
> > we would substantially reduce porting delta to retain C11, there are a
> > number of other things that help with portability from C11 that we can
> > utilized that i hadn't brought up before since it had been resolved to
> > adopt it.
> >
> > it would be really unfortunate to say we aren't going to require C11
> > since that would cause me to have to bring a lot more conditional
> > compile into the tree.
> >
> > just fyi
> >
> As far as I know we are requiring C11, and the meson.build file on main
> tree currently has set the minimum for that. We just haven't got code in
> there yet that uses the C11 atomics, which is the bit that is missing
> from
> the RHEL 7 compiler.
> 
> I agree that we should not actually actively support RHEL 7 - I just
> wouldn't call attention to the fact that it's no longer supported if it
> still happens to work. Once we actually break it, I'm all for
> documenting
> that it's not supported. [NOTE: I both cases, I'm not saying that we
> call
> it out explicitly as supported either - I'm just talking about a release
> note entry saying the opposite!]

If I was using RHEL 7, and DPDK degraded the RHEL 7 support level (e.g. not testing it in CI anymore) with a release, I would certainly want this to be highlighted in the release notes! "Not known to be broken, might work" and "passed validation" are two very different things in a production environment. :-)

Anyway, Bruce's point is valid; it's not binary, so let's not scare RHEL 7 users more than we have to.

> 
> /Bruce