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:roret...@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 <tho...@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
