[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