[dpdk-dev] [PATCH v1 0/4] Generalize PCI specific EAL function/structures

Shreyansh Jain shreyansh.jain at nxp.com
Thu Oct 6 13:43:00 CEST 2016


Hi Thomas,

On Monday 03 October 2016 07:06 PM, Thomas Monjalon wrote:
> 2016-10-03 11:07, Shreyansh Jain:
>> Hi David,
>>
>> On Friday 30 September 2016 09:01 PM, David Marchand wrote:
>>> On Tue, Sep 27, 2016 at 4:12 PM, Shreyansh Jain <shreyansh.jain at nxp.com> wrote:
>>>> (I rebased these over HEAD 7b3c4f3)
>>>>
>>>> These patches were initially part of Jan's original series on SoC
>>>> Framework ([1],[2]). An update to that series, without these patches,
>>>> was posted here [3].
>>>>
>>>> Main motivation for these is aim of introducing a non-PCI centric
>>>> subsystem in EAL. As of now the first usecase is SoC, but not limited to
>>>> it.
>>>>
>>>> 4 patches in this series are independent of each other, as well as SoC
>>>> framework. All these focus on generalizing some structure or functions
>>>> present with the PCI specific code to EAL Common area (or splitting a
>>>> function to be more userful).
>>>
>>> Those patches move linux specifics (binding pci devices using sysfs)
>>> to common infrastucture.
>>> We have no proper hotplug support on bsd, but if we had some common
>>> code we should at least try to make the apis generic.
>>>
>>
>> I am not sure if I understood your point well. Just to confirm - you are
>> stating that the movement done in the patches might not suit BSD.
>> Probably you are talking about (Patch 3/4 and 4/4).
>> Is my understanding correct?
>>
>> So, movement to just Linux area is not enough?
>> I am not well versed with BSD way of doing something similar so if
>> someone can point it out, I can integrate that. (I will investigate it
>> at my end as well).
>>
>> This patchset makes the PCI->EAL movement *only* for Linux for sysfs
>> bind/unbind. (I should add this to cover letter, at the least).
>
> The concern is about function declarations in
> 	lib/librte_eal/common/eal_private.h
> We cannot be sure it can be applicable to something else than Linux.
> As it is implemented in Linux only, it should not be in a common header.
>

Ok. But, digging a little I found at least one more similar case.
'rte_eal_check_module()' which is present in the linuxapp/eal.c and has 
existence in common, but no parallel implementation for BSD exists. This 
function is accessing /sys/modules - which might be Linux specific.

It seems to be a pretty old entry though (dating back to 2014).

-
Shreyansh


More information about the dev mailing list