RFC abstracting atomics

[Tyler Retzlaff]

On Fri, Jan 13, 2023 at 09:40:20PM +0530, Jerin Jacob wrote:
> 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

so just a caution that this mail thread isn't proposing any bump in C
standard requirement, it's about introducing an atomics abstraction
though it's really easy to start talking about standard C i understand.

let's move discussion about dpdk minimum standard C to the thread Bruce
posted yesterday to avoid distraction about atomics abstraction
integration.

Bruce's thread addressing setting the minimum standard is here.
http://mails.dpdk.org/archives/dev/2023-January/258925.html

thanks!