> 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
