Re: [PATCH] eal: introduce atomics abstraction

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Feb 02, 2023 at 11:00:23AM -0800, Tyler Retzlaff wrote:
> On Thu, Feb 02, 2023 at 09:43:58AM +0100, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > Sent: Wednesday, 1 February 2023 22.41
> > > 
> > > On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli wrote:
> > > >
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > Sent: Tuesday, January 31, 2023 4:42 PM
> > > > >
> > > > > Honnappa, please could you give your view on the future of atomics
> > > in DPDK?
> > > > Thanks Thomas, apologies it has taken me a while to get to this
> > > discussion.
> > > >
> > > > IMO, we do not need DPDK's own abstractions. APIs from stdatomic.h
> > > (stdatomics as is called here) already serve the purpose. These APIs
> > > are well understood and documented.
> > > 
> > > i agree that whatever atomics APIs we advocate for should align with
> > > the
> > > standard C atomics for the reasons you state including implied
> > > semantics.
> > > 
> > > >
> > > > For environments where stdatomics are not supported, we could have a
> > > stdatomic.h in DPDK implementing the same APIs (we have to support only
> > > _explicit APIs). This allows the code to use stdatomics APIs and when
> > > we move to minimum supported standard C11, we just need to get rid of
> > > the file in DPDK repo.
> > 
> > Perhaps we can use something already existing, such as this:
> > https://android.googlesource.com/platform/bionic/+/lollipop-release/libc/include/stdatomic.h
> > 
> > > 
> > > my concern with this is that if we provide a stdatomic.h or introduce
> > > names
> > > from stdatomic.h it's a violation of the C standard.
> > > 
> > > references:
> > >  * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3.
> > >  * GNU libc manual
> > >    https://www.gnu.org/software/libc/manual/html_node/Reserved-
> > > Names.html
> > > 
> > > in effect the header, the names and in some instances namespaces
> > > introduced
> > > are reserved by the implementation. there are several reasons in the
> > > GNU libc
> > > manual that explain the justification for these reservations and if
> > > if we think about ODR and ABI compatibility we can conceive of others.
> > 
> > I we are going to move to C11 soon, I consider the shim interim, and am inclined to ignore these warning factors.
> > 
> > If we are not moving to C11 soon, I would consider these disadvantages more seriously.
> 
> I think it's reasonable to assume that we are talking years here.
> 
> We've had a few discussions about minimum C standard. I think my first
> mailing list exchanges about C99 was almost 2 years ago. Given that we
> still aren't on C99 now (though i know Bruce has a series up) indicates
> that progression to C11 isn't going to happen any time soon and even if
> it was the baseline we still can't just use it (reasons described
> later).
> 
> Also, i'll point out that we seem to have accepted moving to C99 with
> one of the holdback compilers technically being non-conformant but it
> isn't blocking us because it provides the subset of C99 features without
> being conforming that we happen to be using.
> 
What compiler is this? As far as I know, all our currently support
compilers claim to support C99 fully. All should support C11 also,
except for GCC 4.8 on RHEL/CentOS 7. Once we drop support for Centos 7, I
think we can require at minimum a c11 compiler for building DPDK itself.
I'm still a little uncertain about requiring that users build their own
code with -std=c11, though.

/Bruce