[PATCH v6 1/6] dpdk: do not force C linkage on include file dependencies

Mattias Rönnblom hofors at lysator.liu.se
Tue Sep 17 11:30:02 CEST 2024


On 2024-09-16 14:05, David Marchand wrote:
> Hello,
> 
> On Tue, Sep 10, 2024 at 10:41 AM Mattias Rönnblom
> <mattias.ronnblom at ericsson.com> wrote:
>> diff --git a/lib/acl/rte_acl_osdep.h b/lib/acl/rte_acl_osdep.h
>> index 3c1dc402ca..e4c7d07c69 100644
>> --- a/lib/acl/rte_acl_osdep.h
>> +++ b/lib/acl/rte_acl_osdep.h
>> @@ -5,10 +5,6 @@
>>   #ifndef _RTE_ACL_OSDEP_H_
>>   #define _RTE_ACL_OSDEP_H_
>>
>> -#ifdef __cplusplus
>> -extern "C" {
>> -#endif
>> -
>>   /**
>>    * @file
>>    *
>> @@ -49,6 +45,10 @@ extern "C" {
>>   #include <rte_cpuflags.h>
>>   #include <rte_debug.h>
>>
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>>   #ifdef __cplusplus
>>   }
>>   #endif
> 
> This part is a NOOP, so we can just drop it.
> 

I did try to drop such NOOPs, but then something called 
sanitycheckcpp.exe failed the build because it required 'extern "C"' in 
those header files.

Isn't that check superfluous? A missing 'extern "C"' would be detected 
at a later stage, when the dummy C++ programs are compiled against the 
public header files.

If we agree santifycheckcpp.exe should be fixed, is that a separate 
patch or need it be a part of this patch set?

> I found this occurence in other files of the patch.
> 
> $ git show lib/ | grep -E '^ .*__cplusplus|diff' | grep -B1
> __cplusplus | sed -ne 's/^diff --git a\/\(.*\) b\/.*$/\1/p' | while
> read file; do git show -- $file | tr '\n' ' ' | grep -q ' +#ifdef
> __cplusplus +extern "C" { +#endif +  #ifdef __cplusplus' && echo
> $file; done
> lib/acl/rte_acl_osdep.h
> lib/eal/arm/include/rte_cpuflags_32.h
> lib/eal/arm/include/rte_cpuflags_64.h
> lib/eal/arm/include/rte_power_intrinsics.h
> lib/eal/loongarch/include/rte_cpuflags.h
> lib/eal/loongarch/include/rte_power_intrinsics.h
> lib/eal/ppc/include/rte_cpuflags.h
> lib/eal/ppc/include/rte_power_intrinsics.h
> lib/eal/riscv/include/rte_cpuflags.h
> lib/eal/riscv/include/rte_power_intrinsics.h
> lib/eal/x86/include/rte_cpuflags.h
> lib/eal/x86/include/rte_power_intrinsics.h
> lib/ipsec/rte_ipsec.h
> lib/pdcp/rte_pdcp.h
> lib/ring/rte_ring_elem.h
> 
> 
>> diff --git a/lib/eal/arm/include/rte_io.h b/lib/eal/arm/include/rte_io.h
>> index f4e66e6bad..658768697c 100644
>> --- a/lib/eal/arm/include/rte_io.h
>> +++ b/lib/eal/arm/include/rte_io.h
>> @@ -5,14 +5,14 @@
>>   #ifndef _RTE_IO_ARM_H_
>>   #define _RTE_IO_ARM_H_
>>
>> -#ifdef __cplusplus
>> -extern "C" {
>> -#endif
>> -
>>   #ifdef RTE_ARCH_64
>>   #include "rte_io_64.h"
>>   #else
>>   #include "generic/rte_io.h"
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>>   #endif
> 
> I suspect it is the reason for the CI build error on ARM.
> This block should be out of the #endif, but then with the next lines,
> it ends up as a noop.
> 
>>
>>   #ifdef __cplusplus
> 
> 
>> diff --git a/lib/eal/arm/include/rte_pause.h b/lib/eal/arm/include/rte_pause.h
>> index 6c7002ad98..8f35d60a6e 100644
>> --- a/lib/eal/arm/include/rte_pause.h
>> +++ b/lib/eal/arm/include/rte_pause.h
>> @@ -5,14 +5,14 @@
>>   #ifndef _RTE_PAUSE_ARM_H_
>>   #define _RTE_PAUSE_ARM_H_
>>
>> -#ifdef __cplusplus
>> -extern "C" {
>> -#endif
>> -
>>   #ifdef RTE_ARCH_64
>>   #include <rte_pause_64.h>
>>   #else
>>   #include <rte_pause_32.h>
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>>   #endif
> 
> Idem, probably breaking build for ARM.
> 
> 
>> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
>> index f859707744..0a4f3f8528 100644
>> --- a/lib/eal/include/generic/rte_atomic.h
>> +++ b/lib/eal/include/generic/rte_atomic.h
>> @@ -17,6 +17,10 @@
>>   #include <rte_common.h>
>>   #include <rte_stdatomic.h>
>>
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>>   #ifdef __DOXYGEN__
>>
>>   /** @name Memory Barrier
>> @@ -1156,4 +1160,8 @@ rte_atomic128_cmp_exchange(rte_int128_t *dst,
>>
>>   #endif /* __DOXYGEN__ */
>>
>> +#ifdef __cplusplus
>> +}
>> +#endif
>> +
> 
> I would move under #ifdef DOXYGEN.
> 

Why? The pattern now is "almost always directly after the #includes". 
That is better than before, but not ideal. C linkage should only be 
covering functions and global variables declared, I think.

> The rest looks good to me.
> 
> 

Thanks for the help!



More information about the dev mailing list