RE: RFC abstracting atomics

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

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