On 9/26/2017 1:43 PM, Shreyansh Jain wrote:
> On Tuesday 19 September 2017 07:27 PM, Shreyansh Jain wrote:
>> On Tuesday 19 September 2017 07:10 PM, Ferruh Yigit wrote:
>>> On 9/19/2017 2:18 PM, Shreyansh Jain wrote:
>>>> On Monday 18 September 2017 08:19 PM, Ferruh Yigit wrote:
>>>>> On 9/9/2017 12:20 PM, Shreyansh Jain wrote:
>>>>>> From: Hemant Agrawal <hemant.agra...@nxp.com>
>>>>>>
>>>>>> Linked list, bit operations and compatibility macros.
>>>>>>
>>>>>> Signed-off-by: Geoff Thorpe <geoff.tho...@nxp.com>
>>>>>> Signed-off-by: Hemant Agrawal <hemant.agra...@nxp.com>
>>>>>
>
> [...]
>
>>>>>> + */
>>>>>
>>>
>>> <...>
>>>
>>>>>> +
>>>>>> +#ifndef __DPAA_LIST_H
>>>>>> +#define __DPAA_LIST_H
>>>>>> +
>>>>>> +/****************/
>>>>>> +/* Linked-lists */
>>>>>> +/****************/
>>>>>
>>>>> Do we need to maintain a linked list implementation, why no just use
>>>>> sys/queue.h ones as done many places in DPDK?
>>>>>
>>>>>> +
>>>>>> +struct list_head {
>>>>>> + struct list_head *prev;
>>>>>> + struct list_head *next;
>>>>>> +};
>>>>>> +
>>>>>
>>>>> <...>
>>>>>
>>>>
>>>> The underlying DPAA infrastructure code is shared between kernel and
>>>> userspace. That is why, changing the internal headers (for example,
>>>> using RTE_* queues) is something I want to avoid until absolutely
>>>> necessary. The outer layers (drivers/*/dpaa/<here>) are something I am
>>>> trying to keep as close to possible to DPDK.
>>>
>>> I understand you want to escape from maintaining a copy of common files
>>> for DPDK, this has been done by many drivers, as not changing "base"
>>> files, this makes sense.
>>>
>>> But for this case, file is "dpaa_list.h" and as far as I can see all it
>>> has is linked list implementation, this looked easy to exclude, but if
>>> not you can ignore the comment.
>>
>> Got your point. I will respin and see how much is the impact.
>> Thanks for inputs.
>
> I tried to work around the dpaa_list.h use in DPAA code - but, the
> changes are subtle but large in number - though, restricted only to base
> framework.
> I would prefer to skip this for a while as the driver is stable now. I
> would probably do this change in a incremental manner to keep it traceable.
>
> Ferruh, Is that OK with you?
That is OK, if it is not easy to escape from it.
