On Fri, Jan 13, 2023 at 7:49 PM Ben Magistro <konce...@gmail.com> wrote: > > As a user/developer I'll put a vote on Morten's side here. There are other > libraries we utilize that have stated x.y.z is the last version that will > support w, beginning on version l.m.n it will be standard o. I personally > don't think a project asking for C11 support at a minimum would be > unreasonable or overly burdensome.
+1 Instead of polluting new DPDK code for legacy applications(If some reason they want absolutely want to move latest and greatest DPDK), I think it should be possible for legacy application selectivity turning on/of like "#pragma GCC diagnostic warning "-std=c++11" or worst case move DPDK function in wrapper(which is already case in most of the applications) in their app and compile the wrapper only with C11 > > In that vein I thought there was a supported operating systems page (can't > find it for 22.11 but did find it for an older version, 17.05). On more > recent versions, there is the tested platforms page. Going back to the > oldest LTS, 20.11 (and current 22.11 which includes some older OS not on the > 20.11 list), I would be shocked if any of the listed operating systems didn't > support C11 out of the box. > > Just my $0.01 > > On Wed, Jan 11, 2023 at 10:07 AM Morten Brørup <m...@smartsharesystems.com> > wrote: >> >> > From: Bruce Richardson [mailto:bruce.richard...@intel.com] >> > Sent: Wednesday, 11 January 2023 15.18 >> > >> > On Wed, Jan 11, 2023 at 01:46:02PM +0100, Morten Brørup wrote: >> > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] >> > > > Sent: Wednesday, 11 January 2023 12.57 >> > > > >> > > > On Wed, Jan 11, 2023 at 11:23:07AM +0100, Morten Brørup wrote: >> > > > > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] >> > > > > > Sent: Wednesday, 11 January 2023 11.10 >> > > > > > >> > > > > > One additional point that just became clear to me when I >> > started >> > > > > > thinking >> > > > > > about upping our DPDK C-standard-baseline. We need to be >> > careful >> > > > what >> > > > > > we >> > > > > > are considering when we up our C baseline. We can mandate a >> > > > specific >> > > > > > compiler minimum and C version for compiling up DPDK itself, >> > but I >> > > > > > think we >> > > > > > should not mandate that for the end applications. >> > > > > >> > > > > Why not? >> > > > > >> > > > > And do you consider this backwards compatibility a build time or >> > run >> > > > time requirement? >> > > > > >> > > > > > >> > > > > > That means that our header files, such as atomics, should not >> > > > require >> > > > > > C99 >> > > > > > or C11 even if the build of DPDK itself does. More >> > specifically, >> > > > even >> > > > > > if we >> > > > > > bump DPDK minimum to C11, we should still allow apps to build >> > using >> > > > > > older >> > > > > > compiler settings. >> > > > > > >> > > > > > Therefore, we probably need to maintain non-C11 atomics code >> > paths >> > > > in >> > > > > > headers beyond the point at which DPDK itself uses C11 as a >> > code >> > > > > > baseline. >> > > > > >> > > > > Am I misunderstanding your suggestion here: Code can be C11, but >> > all >> > > > APIs and header files must be C89? >> > > > > >> > > > > Wouldn't that also prevent DPDK inline functions from being C11? >> > > > > >> > > > Yes, it would. >> > > > >> > > > Now, perhaps we don't need to ensure that our headers have strict >> > C89 >> > > > compatibility, but I think we need to be very careful about >> > mandating >> > > > that >> > > > end-user apps use particular c standard settings when compiling >> > their >> > > > own >> > > > code. >> > > >> > > I get your point, Bruce, but I disagree. >> > > >> > > There should be a limit for how backwards compatible we want DPDK to >> > be, and the limit should certainly not be C89. It might be C99 for a >> > while, but it should soon be C11. >> > > >> > > If someone is stuck with a very old C compiler, and already rely on >> > (extended) LTS for their compiler and runtime environment, why would >> > they expect bleeding edge DPDK to cater for them? They can use some old >> > DPDK version and rely on DPDK LTS. >> > > >> > > If you want to use an old compiler, you often have to use old >> > libraries too, as new libraries often require newer compilers. This >> > also applies to the Linux kernel. I don't see why DPDK should be any >> > different. >> > > >> > > But... DPDK LTS is only two years!?! My point is: What you are >> > describing is not a DPDK problem, it is a DPDK LTS policy problem. >> > > >> > >> > I don't see it as a compiler problem, but as a codebase one. It doesn't >> > matter if your compiler supports C11 if your codebase is using legacy >> > features from C89 that are no longer supported by later versions. >> > Changing >> > compilers can be tricky, but updating a large legacy code-base is a >> > much >> > more challenging proposition. There is a lot of old code out there in >> > the >> > world! >> >> OK. But my same argument applies: Why would you need to use a brand new DPDK >> release in your project when the rest of your code base is ancient? In that >> case, you should rely on DPDK LTS. >> >> > >> > That said, I would hope that there are few large codebases out there >> > that >> > won't compile with a C99 or C11 standard language level, and there >> > aren't >> > that many things that should cause problems. However, I don't really >> > know for >> > sure, so urge caution. >> > >> > /Bruce >>
