[PATCH 1/2] eal: fix constraints on stdatomic API

Jie Hai haijie1 at huawei.com
Fri Dec 15 03:47:36 CET 2023


On 2023/12/12 2:53, Tyler Retzlaff wrote:
> On Mon, Dec 11, 2023 at 03:39:03PM +0800, Jie Hai wrote:
>> The first parameter of rte_atomic_exchange_explicit() must be a
>> pointer to _Atomic type. If run command "meson setup --werror
>> -Denable_stdatomic=true build && ninja -C build", error will occur.
>> Thia patch fixes it.
>>
>> Fixes: 1ec6a845b5cb ("eal: use stdatomic API in public headers")
>> Cc: stable at dpdk.org
>>
>> Signed-off-by: Jie Hai <haijie1 at huawei.com>
>> ---
>>   app/test/test_atomic.c               |  6 +++---
>>   lib/eal/include/generic/rte_atomic.h | 12 ++++++------
>>   2 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/app/test/test_atomic.c b/app/test/test_atomic.c
>> index db07159e81ab..c3cb3ae0ea57 100644
>> --- a/app/test/test_atomic.c
>> +++ b/app/test/test_atomic.c
>> @@ -347,9 +347,9 @@ typedef union {
>>   const uint8_t CRC8_POLY = 0x91;
>>   uint8_t crc8_table[256];
>>   
>> -volatile uint16_t token16;
>> -volatile uint32_t token32;
>> -volatile uint64_t token64;
>> +volatile RTE_ATOMIC(uint16_t) token16;
>> +volatile RTE_ATOMIC(uint32_t) token32;
>> +volatile RTE_ATOMIC(uint64_t) token64;
> 
> subject to my comment below, volatile qualification can be removed.
> 
>>   
>>   static void
>>   build_crc8_table(void)
>> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
>> index 0e639dad76a4..38c3b41f9c68 100644
>> --- a/lib/eal/include/generic/rte_atomic.h
>> +++ b/lib/eal/include/generic/rte_atomic.h
>> @@ -207,11 +207,11 @@ rte_atomic16_cmpset(volatile uint16_t *dst, uint16_t exp, uint16_t src)
>>    *   The original value at that location
>>    */
>>   static inline uint16_t
>> -rte_atomic16_exchange(volatile uint16_t *dst, uint16_t val);
>> +rte_atomic16_exchange(volatile RTE_ATOMIC(uint16_t) *dst, uint16_t val);
> 
> the existing rte_atomicNN (the old non-standard ones) are deprecated and will
> be eventually removed so there isn't a lot of value in churning their
> signatures to wrap the rte_stdatomic macros.
> 
> the right thing to do here to just change the calling code to use the generic
> rte_stdatomic macros directly so we can eventually remove
> rte_atomicNN_xxx.
> 
> ty
> 
Hi, Tyler Retzlaff,

Thank you for your review.

As I understand it, this code is used to test the API
rte_atomXXX_change, and the call here should not be modified.

Since the current problem affects compilation, I think it can be solved 
first.

What do you think?

Thanks,
Jie Hai
> .


More information about the dev mailing list