[dpdk-dev] [PATCH] mk: fix missing link of librte_vhost in shared, non-combined config

[Panu Matilainen]

On 02/13/2015 03:18 PM, Thomas Monjalon wrote:
> 2015-02-13 12:33, Panu Matilainen:
>> On 02/13/2015 11:28 AM, Thomas Monjalon wrote:
>>> 2015-02-13 09:27, Panu Matilainen:
>>>> On 02/12/2015 05:44 PM, Thomas Monjalon wrote:
>>>>> A library is considered as a plugin if there is no public API and it
>>>>> registers itself. That's the case of normal PMD.
>>>>> But bonding and Xen have some library parts with public API.
>>>>> It has been discussed and agreed for bonding but I'm not aware of the Xen case.
>>>>
>>>> Fair enough, thanks for the explanation.
>>>>
>>>> Just wondering about versioning of these things - currently all the PMDs
>>>> are versioned as well, which is slightly at odds with their expected
>>>> usage, dlopen()'ed items usually are not versioned because it makes the
>>>> files moving targets. But if a plugin can be an library too then it
>>>> clearly needs to be versioned as well.
>>>
>>> Not sure to understand your considerations.
>>> Plugins must be versioned because there can be some incompatibilities
>>> like mbuf rework.
>>
>> Plugins are version-dependent obviously, but the issue is somewhat
>> different from library versioning. Plugins are generally consumers of
>> the versioned ABIs, whereas libraries are the providers.
>>
>>>> I'm just thinking of typical packaging where the unversioned *.so
>>>> symlinks are in a -devel subpackage and the versioned libraries are in
>>>> the main runtime package. Plugins should be loadable by a stable
>>>> unversioned name always, for libraries the linker handles it behind the
>>>> scenes. So in packaging these things, plugin *.so links need to be
>>>> handled differently (placed into the main package) from others. Not
>>>> rocket science to filter by 'pmd' in the name, but a new twist anyway
>>>> and easy to get wrong.
>>>>
>>>> One possibility to make it all more obvious might be having a separate
>>>> directory for plugins, the mixed case ccould be handled by symlinks.
>>>
>>> I think I don't understand which use case you are trying to solve.
>>
>> Its a usability/documentation issue more than a technical one. If plugin
>> DSO's are versioned (like they currently are), then loading them via eg
>> -d becomes cumbersome since you need to hunt down and provide the
>> versioned name, eg "testpmd -d librte_pmd_pcap.so.1 [...]"
>>
>> Like said above, it can be worked around by leaving the unversioned
>> symlinks in place for plugins in runtime (library) packages, but that
>> sort of voids the point of versioning. One possibility would be
>> introducing a per-version plugin directory that would be used as the
>> default path for dlopen() unless an absolute path is used.
>
> It makes me think that instead of using a -d option per plugin, why not
> adding a -D option to load all plugins from a directory?

Are you thinking of "-D <plugindir>" or just -D (to use a build-time 
hardwired directory)?

	- Panu -