[PATCH 1/6] eal: provide rte stdatomics optional atomics API

[Morten Brørup]

> From: Tyler Retzlaff [mailto:roretzla at linux.microsoft.com]
> Sent: Friday, 11 August 2023 17.55
> 
> On Fri, Aug 11, 2023 at 11:42:12AM +0200, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roretzla at linux.microsoft.com]
> > > Sent: Friday, 11 August 2023 03.32
> > >
> > > Provide API for atomic operations in the rte namespace that may
> > > optionally be configured to use C11 atomics with meson
> > > option enable_stdatomics=true
> > >
> > > Signed-off-by: Tyler Retzlaff <roretzla at linux.microsoft.com>
> > > ---

[...]

> >
> > Move the (changed) C11 memory order type definition here:
> >
> > /* The memory order is an enumerated type in C11. */
> > #define memory_order rte_memory_order

No objections to your typedef in v2.

[...]

> > > +#ifdef __ATOMIC_SEQ_CST
> > > +_Static_assert(rte_memory_order_seq_cst == __ATOMIC_SEQ_CST,
> > > +	"rte_memory_order_seq_cst == __ATOMIC_SEQ_CST");
> > > +#endif
> >
> > Excellent idea adding these _Static_asserts!
> >
> > Have you tested (with the toolchain you are targeting with this
> _Static_assert) that e.g. __ATOMIC_RELAXED is actually #defined, so the
> preprocessor can see it? (I guess that being a built-it, it might not be a
> #define, it might be a magic value known by the compiler only.)
> 
> * llvm and gcc both expose it as a built-in #define for test builds i
>   have run. worst case the assert is lost if it isn't.

I only wanted to check that we didn't always hit the "worst case" where the static_assert is lost, so thank you for the confirmation regarding GCC/clang.

> * since i have to handle non-{clang,gcc} too i still guard with ifdef

Agree.

> * i do need to switch to using assert.h static_assert macro to
>   inter-operate with c++ in v2

OK. I reviewed that in v2 too.

-Morten