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

[Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

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:
> >>> 2015-02-11 12:31, Gonzalez Monroy, Sergio:
> >>>> From: Panu Matilainen [mailto:pmatilai-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org]
> >>>>> 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.
> 
> 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 [...]"

Oh it's clearer now.

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

Feel free to update the spec file in pkg/ directory.
Thanks