[dpdk-dev] [PATCH v8 01/25] eal: define macro container_of

Shreyansh Jain shreyansh.jain at nxp.com
Tue Aug 30 06:27:59 CEST 2016


Hi Ferruh,

On Monday 29 August 2016 10:13 PM, Ferruh Yigit wrote:
> On 8/26/2016 2:56 PM, Shreyansh Jain wrote:
>> Signed-off-by: Jan Viktorin <viktorin at rehivetech.com>
>> Signed-off-by: Shreyansh Jain <shreyansh.jain at nxp.com>
>> ---
>>  lib/librte_eal/common/include/rte_common.h | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
>> index 332f2a4..a9b6792 100644
>> --- a/lib/librte_eal/common/include/rte_common.h
>> +++ b/lib/librte_eal/common/include/rte_common.h
>> @@ -322,6 +322,22 @@ rte_bsf32(uint32_t v)
>>  #define offsetof(TYPE, MEMBER)  __builtin_offsetof (TYPE, MEMBER)
>>  #endif
>>
>> +/**
>> + * Return pointer to the wrapping struct instance.
>> + * Example:
>> + *
>> + *  struct wrapper {
>> + *      ...
>> + *      struct child c;
>> + *      ...
>> + *  };
>> + *
>> + *  struct child *x = obtain(...);
>> + *  struct wrapper *w = container_of(x, struct wrapper, c);
>> + */
>> +#define container_of(p, type, member) \
>> +	((type *) (((char *) (p)) - offsetof(type, member)))
>> +
>>  #define _RTE_STR(x) #x
>>  /** Take a macro value and get a string version of it */
>>  #define RTE_STR(x) _RTE_STR(x)
>>
>
> This gives compilation error for mlx5, because the libraries mlx depends
> defines same macro:
> ..../rte_common.h:338:9: error: 'container_of' macro redefined
> /usr/include/infiniband/verbs.h:77:9: note: previous definition is here

I thought testing with scripts/test-build.sh and default configuration 
would compile all drivers - I was wrong. I will retest the patches and 
release again.

Is there a better way to test that no driver breaks? Any particular 
parameters I should use for test-build.sh?

I used 'x86_64-native-linuxapp-gcc+default+debug+shared' for all patches.

>
> Does it make sense to protect macro with
> #ifndef container_of
> ....
> #endif
>
> OR
>
> add a dpdk prefix?
>
>
> Regards,
> ferruh
>

-
Shreyansh



More information about the dev mailing list