Thread (27 messages) 27 messages, 6 authors, 2016-10-14

Re: [PATCH v1 0/4] Generalize PCI specific EAL function/structures

From: Shreyansh Jain <hidden>
Date: 2016-10-06 11:42:08

Hi Thomas,

On Monday 03 October 2016 07:06 PM, Thomas Monjalon wrote:
2016-10-03 11:07, Shreyansh Jain:
quoted
Hi David,

On Friday 30 September 2016 09:01 PM, David Marchand wrote:
quoted
On Tue, Sep 27, 2016 at 4:12 PM, Shreyansh Jain [off-list ref] wrote:
quoted
(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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help