RFC abstracting atomics

[Jerin Jacob]

On Fri, Jan 13, 2023 at 7:49 PM Ben Magistro <koncept1 at 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 <mb at smartsharesystems.com> wrote:
>>
>> > From: Bruce Richardson [mailto:bruce.richardson at 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 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!
>>
>> 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
>>