On Tue Nov 03 11:48:57 +0000 2015, Ferruh Yigit wrote:
> On Tue, Nov 03, 2015 at 01:31:45PM +0200, Panu Matilainen wrote:
> > On 11/03/2015 01:02 PM, Ferruh Yigit wrote:
> >> On Tue, Nov 03, 2015 at 08:48:16AM +0200, Panu Matilainen wrote:
> >>> On 11/02/2015 06:42 PM, Eric Kinzie wrote:
> >>>> On Mon Nov 02 12:23:47 +0200 2015, Panu Matilainen wrote:
> >>>>> On 11/01/2015 08:17 PM, Thomas Monjalon wrote:
> >>>>>> 2015-10-19 08:36, Eric Kinzie:
> >>>>>>> Size of struct rte_eth_bond_8023ad_conf changed. Increment
> >>>>>>> LIBABIVER
> >>>>>>> and version bond_mode_8023ad_setup and bond_mode_8023ad_conf_get
> >>>>>>> functions.
> >>>>>> [...]
> >>>>>>> +VERSION_SYMBOL(bond_mode_8023ad_setup, _v20, 2.0);
> >>>>>> [...]
> >>>>>>> +BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>>>>>> +MAP_STATIC_SYMBOL(void bond_mode_8023ad_setup(struct rte_eth_dev
> >>>>>>> *dev, struct rte_eth_bond_8023ad_conf *conf), \
> >>>>>>> + bond_mode_8023ad_setup_v22);
> >>>>>>
> >>>>>> I'm sorry it doesn't work well when trying to build a combined lib:
> >>>>>>
> >>>>>> ld: libdpdk.so: version node not found for symbol
> >>>>>> bond_mode_8023ad_setup@@DPDK_2.2
> >>>>>>
> >>>>>> The symbols are OK in the .o file:
> >>>>>> 0000000000002340 g F .text 0000000000000171
> >>>>>> bond_mode_8023ad_setup@@DPDK_2.2
> >>>>>> 0000000000002260 g F .text 00000000000000da
> >>>>>> bond_mode_8023ad_setup at DPDK_2.0
> >>>>>> 0000000000002260 g F .text 00000000000000da
> >>>>>> bond_mode_8023ad_setup_v20
> >>>>>> 0000000000002340 g F .text 0000000000000171
> >>>>>> bond_mode_8023ad_setup_v22
> >>>>>> 0000000000000000 *UND* 0000000000000000 bond_mode_8023ad_setup
> >>>>>>
> >>>>>> I don't understand the problem and I am considering disabling
> >>>>>> versioning in
> >>>>>> combined library.
> >>>>>>
> >>>>>> Any idea?
> >>>>>>
> >>>>>
> >>>>> The .map additions look incorrect to me:
> >>>>>
> >>>>>> diff --git a/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>> b/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>> index 22bd920..7f78717 100644
> >>>>>> --- a/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>> +++ b/drivers/net/bonding/rte_eth_bond_version.map
> >>>>>> @@ -17,6 +17,9 @@ DPDK_2.0 {
> >>>>>> rte_eth_bond_slaves_get;
> >>>>>> rte_eth_bond_xmit_policy_get;
> >>>>>> rte_eth_bond_xmit_policy_set;
> >>>>>> + rte_eth_bond_8023ad_ext_collect;
> >>>>>> + rte_eth_bond_8023ad_ext_distrib;
> >>>>>> + rte_eth_bond_8023ad_ext_slowtx;
> >>>>>
> >>>>> These symbols didn't exist in DPDK 2.0 but are only being added
> >>>>> here. So why are they being added to the 2.0 section?
> >>>>
> >>>> Yes, I think these should probably be moved.
> >>>>
> >>>>
> >>>>>>
> >>>>>> local: *;
> >>>>>> };
> >>>>>> @@ -27,3 +30,10 @@ DPDK_2.1 {
> >>>>>> rte_eth_bond_free;
> >>>>>>
> >>>>>> } DPDK_2.0;
> >>>>>> +
> >>>>>> +DPDK_2.2 {
> >>>>>> + local
> >>>>>> +
> >>>>>> + bond_mode_8023ad_conf_get;
> >>>>>> + bond_mode_8023ad_setup;
> >>>>>> +} DPDK_2.1;
> >>>>>
> >>>>> These are marked local, as in, "not exported" which doesn't seem
> >>>>> right. Also they're lacking the rte_eth_ prefix. AFAICS this is what
> >>>>> the symbol export map should look like here:
> >>>>
> >>>>
> >>>> These were not exported to begin with. But after versioning these
> >>>> functions, they are exported unless explicitly declared to be local here.
> >>>>
> >>>
> >>> And this does not ring any warning bells? :)
> >>>
> >>> Sorry, I was not looking at the patch as a whole. You're declaring these
> >>> symbols as exported with the versioning macros, eg
> >>>
> >>> BIND_DEFAULT_SYMBOL(bond_mode_8023ad_setup, _v22, 2.2);
> >>>
> >>> ...and then explicitly telling it to not export them by declaring local,
> >>> and
> >>> then we wonder why it has trouble finding the symbols.
> >>> The versioning macros wont invent the librte_ prefix for you, you need to
> >>> rename the functions accordingly.
> >>>
> >>> But all this versioning gymnastics is moot anyway because you declare the
> >>> ABI incompatible:
> >>>
> >>> -LIBABIVER := 1
> >>> +LIBABIVER := 2
> >>>
> >>> This changes the library soname, so no binary compiled against the
> >>> previous
> >>> version can possibly use it anymore. As in, by definition there can be no
> >>> callers of the _v20 variants after this ABI version bump.
> >>>
> >> An observation: even soname is different, just renaming .so file itself
> >> works.
> >>
> >> And this can be useful for the case:
> >> libx.so.1 provides functions A, B, C
> >> app1 compiled against libx.so.1, using only function B
> >>
> >> libx.so.1 updated only thefunction A and become libx.so.2
> >> app1 still can run successfully by re-naming lib to libx.so.1 (even soname
> >> is libx.so.2)
> >>
> >> But for this usage, user needs to know which function updated and is it
> >> safe or not to use this library,
> >> I wonder if there is an automatic way of resolving this dependency.
> >
> > Erm, no. The whole point of changing soname and the physical filename is to
> > tell others it is incompatible with earlier versions. Yes you can rename
> > the
> > file and get lucky (or not), just like you can play Russian roulette.
> > Neither are particularly healthy ideas.
> >
> > Symbol version exists in part to allow libraries to evolve while
> > maintaining
> > compatibility, but it requires careful planning and programming. When
> > public
> > structs change, the structs would have to be versioned too, and from there
> > on it starts getting more and more complicated.
> >
>
> If we strictly want to prevent using old library, whenever LIBABIVER
> increased, we should update .map as following, right?
>
> FROM: (dpdk2.1)
> ================
> DPDK_2.0 {
> A;
> B;
> C;
> };
>
> DPDK_2.1 {
> D;
> E;
> };
>
> LIBABIVER=1
> ================
>
> TO: (dpdk2.2)
> ================
> DPDK_2.2 {
> A;
> B;
> C;
> D;
> E;
> };
>
> LIBABIVER=2
> ================
>
>
> So this won't work for anybody without luck factor, I think currently we are
> not doing this.
>
>
> thanks,
> ferruh
>
>
Panu, Ferruh, is there agreement on an acceptable approach to this?
Eric
