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

[Thomas Monjalon]

2015-02-13 09:27, Panu Matilainen:
> On 02/12/2015 05:44 PM, Thomas Monjalon wrote:
> > 2015-02-11 12:31, Gonzalez Monroy, Sergio:
> >> From: Panu Matilainen [mailto:pmatilai at redhat.com]
> >>> On 02/11/2015 12:51 PM, Gonzalez Monroy, Sergio wrote:
> >>>> I think that vhost is being linked in the wrong place (plugins section).
> >>>> The plugins only get linked when building static libraries.
> >>>> I think the patch should also remove vhost from the plugins section.
> >>>
> >>> Right, so vhost isn't a pluggable driver in the sense that pmds are. I wont
> >>> claim to be familiar with all this virt-related puzzle pieces :) I'll send an
> >>> updated patch, I was just looking to fix build in my particular config and
> >>> ignored the rest.
> >>>
> >>> On a related note, shouldn't librte_pmd_bond and librte_pmd_xenvirt be
> >>> included in the plugins section along with all the other pmds?
> >>>
> >> Hi Panu,
> >>
> >> Good  question :)
> >>
> >> I did wonder the same thing not long ago.
> >>
> >> I think the reason is that (someone may correct me if I'm wrong) there
> >> are specific unit tests for those pmds (testing extra API) that require
> >> them to always be linked against.
> >
> > 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.

> 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.