[dpdk-dev] [PATCHv7 03/47] common/dpaa2: adding qbman driver

[Hemant Agrawal]

On 3/1/2017 4:30 PM, Thomas Monjalon wrote:
> 2017-02-28 05:27, Shreyansh Jain:
>> From: Ferruh Yigit
>>> On 2/27/2017 10:01 AM, Shreyansh Jain wrote:
>>>> On Friday 24 February 2017 03:28 PM, Ferruh Yigit wrote:
>>>>> We can go with option (1) now, since these are not real APIs to user
>>>>> application, it can be possible to change them if better solution found.
>>>>>
>>>>> Do you think is it good idea to have different naming syntax for those
>>>>> libraries to clarify they are for PMD internal usage?
>>>>>
>>>>
>>>> Indeed. Current name is librte_common_dpaa2_*.
>>>> Do you think librte_drvlib_dpaa2 or librte_drvlib_dpaa2_pmd is better?
>>>
>>> common vs drvlib may not be different for who don't know about these
>>> libraries, what about using "internal" or "private" kind of keyword?
>>
>> I am ok with librte_pvtlib_dpaa2_pmd or librte_pvtlib_dpaa2. Sounds fine?
>> ('internal' is too long and its abbreviation 'int' doesn't make it easier
>> to read. :D )
>
> There is already "lib" in "librte". What about librte_internal_dpaa2_ prefix?
>
Ok. We were just trying to avoid that long name. :)

> Internal is really the best word as you are requesting DPDK to host
> libraries used only for your drivers.
> I thought you agreed to host them outside of the DPDK repository.
> What is your reason to keep pushing in DPDK?
>

I don't think the last discussion closed like this. You suggested [1] 
this as an option during handing of issue with rte.lib.mk causing the 
parallel build dependency of shared lib to fail for drivers/common. 
Ferruh has already fixed that[2].

The drivers/common is an integral part of PMD - very similar to a *base* 
directory of any existing DPDK PMDs. The only difference is that *NXP's 
base* is common across multiple drivers (bus, pool, net, crypto, 
eventdev etc) - all of them interface with SoC using this 'driver 
interface'.  We named it as "driver common lib" - we could not find a 
better way to name it. Probably, a hw driver interface or dpaa2_base is 
a better explanation.

Imagine a PMD which resides within DPDK (dpaa2 pmd) which only has high 
level interfaces with DPDK API and cannot talk to a real hardware (SoC) 
because it lacks the basic driver interface. That would really not make 
that code a 'PMD'.

Probably it would be better if we close what is the scope of a PMD 
before this discussion is to go ahead. And, why would there be a need to 
store this 'lib' externally.

Following is what Neil replied to your suggestion [3]. And we fully 
agree with it.
"Please do not go with suggestion two, the more libraries get hosted 
outside of the project, the less likely any sort of test/build/ongoing 
maintenance from the community can be expected.  If you're going to go 
with solution (2), then you may as well host the entire PMD outside of 
the DPDK project, and that more undesirable."


[1] http://dpdk.org/ml/archives/dev/2017-January/056243.html
[2] http://dpdk.org/ml/archives/dev/2017-January/056321.html
[3] http://dpdk.org/ml/archives/dev/2017-January/056292.html