On 02/16/2015 01:17 PM, Thomas Monjalon wrote: > 2015-02-16 12:01, 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)? > > I'm thinking of "-D <plugindir>". > I understand you would like a "hardwired" default directory which would be > properly packaged by a distribution. Maybe that it could be a build-time > default to load all the plugins of a directory (without option). Then the > -d and -D options would overwrite the build-time default behaviour.
Hmm, indeed. What I generally want is software to just DTRT when at all possible. For plugins, that typically means "load all installed/enabled plugins automatically unless manually overridden". This becomes even more of an issue if/when the "combine everything" libintel_dpdk library in its current form is eliminated (I am fully in favor of that) since that has practically hidden the plugins from its users like openvswitch. - Panu - - Panu -