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

Thomas Monjalon thomas.monjalon at 6wind.com
Mon Oct 3 15:36:07 CEST 2016


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.


More information about the dev mailing list