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

  When building shared, non-combined library, librte_vhost does not
get linked in, causing among other things vhost example to fail
building to do undefined symbols on linkage.

Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
---
 mk/rte.app.mk | 4 ++++
 1 file changed, 4 insertions(+)
  

Hi Panu,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
> Sent: Wednesday, February 11, 2015 8:53 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] mk: fix missing link of librte_vhost in shared,
> non-combined config
> 
> When building shared, non-combined library, librte_vhost does not get
> linked in, causing among other things vhost example to fail building to do
> undefined symbols on linkage.
> 
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
> ---
>  mk/rte.app.mk | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 95dbb0b..55d989e 100644
> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -125,6 +125,10 @@ LDLIBS += -lm
>  LDLIBS += -lrt
>  endif
> 
> +ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
> +LDLIBS += -lrte_vhost
> +endif
> +
>  endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
> 
>  ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
> --
> 2.1.0

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.

Regards,
Sergio
  

On 02/11/2015 12:51 PM, Gonzalez Monroy, Sergio wrote:
> Hi Panu,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen
>> Sent: Wednesday, February 11, 2015 8:53 AM
>> To: dev@dpdk.org
>> Subject: [dpdk-dev] [PATCH] mk: fix missing link of librte_vhost in shared,
>> non-combined config
>>
>> When building shared, non-combined library, librte_vhost does not get
>> linked in, causing among other things vhost example to fail building to do
>> undefined symbols on linkage.
>>
>> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
>> ---
>>   mk/rte.app.mk | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 95dbb0b..55d989e 100644
>> --- a/mk/rte.app.mk
>> +++ b/mk/rte.app.mk
>> @@ -125,6 +125,10 @@ LDLIBS += -lm
>>   LDLIBS += -lrt
>>   endif
>>
>> +ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
>> +LDLIBS += -lrte_vhost
>> +endif
>> +
>>   endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
>>
>>   ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
>> --
>> 2.1.0
>
> 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?

	- Panu -
  

> From: Panu Matilainen [mailto:pmatilai@redhat.com]

> Sent: Wednesday, February 11, 2015 11:26 AM

> To: Gonzalez Monroy, Sergio; dev@dpdk.org

> Subject: Re: [dpdk-dev] [PATCH] mk: fix missing link of librte_vhost in

> shared, non-combined config

> 

> On 02/11/2015 12:51 PM, Gonzalez Monroy, Sergio wrote:

> > Hi Panu,

> >

> >> -----Original Message-----

> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Panu Matilainen

> >> Sent: Wednesday, February 11, 2015 8:53 AM

> >> To: dev@dpdk.org

> >> Subject: [dpdk-dev] [PATCH] mk: fix missing link of librte_vhost in

> >> shared, non-combined config

> >>

> >> When building shared, non-combined library, librte_vhost does not get

> >> linked in, causing among other things vhost example to fail building

> >> to do undefined symbols on linkage.

> >>

> >> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>

> >> ---

> >>   mk/rte.app.mk | 4 ++++

> >>   1 file changed, 4 insertions(+)

> >>

> >> diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 95dbb0b..55d989e

> >> 100644

> >> --- a/mk/rte.app.mk

> >> +++ b/mk/rte.app.mk

> >> @@ -125,6 +125,10 @@ LDLIBS += -lm

> >>   LDLIBS += -lrt

> >>   endif

> >>

> >> +ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) LDLIBS += -lrte_vhost endif

> >> +

> >>   endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS

> >>

> >>   ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)

> >> --

> >> 2.1.0

> >

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

Regards,
Sergio

> 	- Panu -

> 

> 

> 

> 

> 

>
  

2015-02-11 12:31, Gonzalez Monroy, Sergio:
> From: Panu Matilainen [mailto:pmatilai@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.
  

On 02/12/2015 05:44 PM, Thomas Monjalon wrote:
> 2015-02-11 12:31, Gonzalez Monroy, Sergio:
>> From: Panu Matilainen [mailto:pmatilai@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.

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.

	- Panu -
  

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

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@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 [...]"

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.

	- Panu -
  

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

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?
  

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 -
  

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.
  

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 -