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