Re: [dpdk-dev] Further fun with ABI tracking

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 2/22/2017 1:12 PM, Christian Ehrhardt wrote:
> On Tue, Feb 14, 2017 at 9:31 PM, Jan Blunck <jblunck@infradead.org> wrote:
> 
>>> 1. Downstreams to insert Major version into soname
>>> Distributions could insert the DPDK major version (like 16.11) into the
>>> soname and package names. A common example of this is libboost [5].
>>> That would perfectly allow 16.07.<LIBABIVER> to coexist with
>>> 16.11.<LIBABIVER> even if for a given library LIBABIVER did not change.
>>> Yet it would mean that anything depending on the old library will have to
>>> be recompiled to pick up the new code, even if it depends on an ABI that
>> is
>>> still present in the new release.
>>> Also - not a technical reason - but it is clearly more work to force
>> update
>>> all dependencies and clean out old packages for every release.
>>
>> Actually this isn't exactly what I proposed during the summit. Just
>> keep it simple and fix the ABI version of all libraries at 16.11.0.
>> This is a proven approach and has been used for years with different
>> libraries.
> 
> 
> Since there was no other response I'll try to wrap up.
> 
> Yes #1 also is my preferred solution at the moment.
> We tried with individual following the tracking of LIBABIVER upstream but
> as outlined before we hit too many issues.
> I discussed it in the deb_dpdk group which acked as well to use this as
> general approach.
> The other options have too obvious flaws as I listed on my initial report
> and - thanks btw - you added a few more.
> 
> @Bruce - sorry I don't think dropping config options is the solution. Yet
> my suggestion does not prevent you from doing so.

Hi Christian,

Can you please describe this option more?

Does is mean for each DPDK release, distro will release all libraries?

For 16.07:
acl.2, eal.2, ethdev.4, pdump.1

For 16.11:
acl.2, eal.3, ethdev.5, pdump.1

Will dpdk package have following packages:
acl.16.07.2, eal.16.07.2, ethdev.16.07.4, pdump.16.07.1
acl.16.11.2, eal.16.11.3, ethdev.16.11.5, pdump.16.11.1

And for initial OVS usecase, will it be:

OVS
 +---> eal.16.07.2
 +---> pdump.16.11.1
        +---> eal.16.11.3


Assuming above understanding is correct J :

- If same version of the library will be delivered for each DPDK
release, what is the benefit of having fine grained libraries really?

- Above OVS usage still does not look right, I don't believe this is the
intention when library level dependency resolving introduced.

Overall I am for single library, but I can see the benefit of having
multiple small libraries, that is why I vote for option 4 in your
initial mail.

And I agree this can cause problem if not automated, but we already know
the library dependencies, I think a script can be developed to warn a
least, and they can be updated manually.

And isn't the purpose of increasing LIBABIVER to notify application that
library is modified and can't be used with that app anymore.
For DPDK, even if the library is not changed, if another library that it
depends modified, this may mean the behavior of the library may be
changed, so it makes sense to me if library notifies the user for this
case, by increasing its version.

Yes this makes effect of increasing a core library version big, but I
believe this is also true, increasing a core library version almost
means increasing dpdk version.

> 
> 
> 
>> You could easily do this independently of us upstream
>> fixing the ABI problems.
> 
> 
> 
> I agree, but I'd like to suggest the mechanism I want to implement.
> An ack by upstream for the Feature to set such a major ABI would be great.
> Actually since it is optional and can help more people integrating DPDK
> getting it accepted upstream be even better.
> 
> I'll send a patch in reply to this thread later today that implements what
> I have in mind.
> 
>