RFC abstracting atomics

[Bruce Richardson]

On Wed, Jan 11, 2023 at 01:46:02PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson at 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.richardson at 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!

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