RE: RFC abstracting atomics

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

> From: Bruce Richardson [mailto:bruce.richardson@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@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.