> From: Bruce Richardson [mailto:bruce.richard...@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:step...@networkplumber.org] > > > > Sent: Thursday, 10 August 2023 19.03 > > > > > > > > On Thu, 10 Aug 2023 18:49:09 +0200 > > > > Thomas Monjalon <tho...@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 <tho...@monjalon.net> wrote: > > > > > > > > > > > > > > > 03/08/2023 15:36, David Marchand: > > > > > > > > > On Wed, Aug 2, 2023 at 2:32 PM Bruce Richardson > > > > > > > > > <bruce.richard...@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.richard...@intel.com> > > > > > > > > > > Acked-by: Morten Brørup <m...@smartsharesystems.com> > > > > > > > > > > Acked-by: Tyler Retzlaff > <roret...@linux.microsoft.com> > > > > > > > > > Tested-by: Ali Alnubani <alia...@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
