Re: [dpdk-dev] Did we reduce unnecessary linkage too well?

[Panu Matilainen <pmatilai@redhat.com>]

On 09/30/2016 01:15 PM, Bruce Richardson wrote:
> On Thu, Sep 29, 2016 at 09:26:48AM +0200, Christian Ehrhardt wrote:
>> On Thu, Sep 29, 2016 at 9:20 AM, Panu Matilainen <pmatilai@redhat.com>
>> wrote:
>>
>>>
>>> Yup. Set CONFIG_RTE_EAL_PMD_PATH to the path where your PMDs are
>>> installed. Note that since the plugin autoloader in DPDK doesn't make
>>> assumptions about names, it'll try to load *everything* in that path, so
>>> you don't want it pointing to eg /usr/lib directly.
>
> Is this something we should look to change? To me having some sort of
> naming convention might not be a bad thing, so that we can point it at generic
> folders.

Plugins for program/library X are nearly always in a sub-directory of 
their own, outside the linker path because ... well, they're plugins and 
not something you should link to, and having them in separate 
directories makes it possible to have multiple versions co-exist on the 
system by simply placing the plugins into a versioned directory.
That's why the current plugin autoloader is the way it is - it's the 
de-facto standard for dealing with plugins.

The DPDK case is a bit convoluted since some of the alleged plugins also 
provide library APIs, so at least those DSOs need to be present in 
linker paths. Plugins usually also lack soname version, because that 
doesn't make much sense for plugins, libraries with APIs are different 
there too.

Anyway, naming conventions are flimsy and fall apart in situations that 
the directory approach easily handles. So I dont see a point in changing 
that. What *would* be good is creating and populating that directory 
from DPDK "make install" step automatically, at least when 
RTE_EAL_PMD_PATH is set.

	- Panu -






>
> /Bruce
>