From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 610D15A3E for ; Thu, 23 Feb 2017 19:48:53 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 10:48:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,198,1484035200"; d="scan'208";a="1134009646" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.137]) ([10.237.220.137]) by fmsmga002.fm.intel.com with ESMTP; 23 Feb 2017 10:48:39 -0800 To: Christian Ehrhardt , Jan Blunck References: Cc: dev , "cjcollier@linuxfoundation.org" , ricardo.salveti@linaro.org, Luca Boccassi From: Ferruh Yigit Message-ID: <6d7ee27e-8d96-7741-3cc0-415e5486ad48@intel.com> Date: Thu, 23 Feb 2017 18:48:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] Further fun with ABI tracking X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 18:48:53 -0000 On 2/22/2017 1:12 PM, Christian Ehrhardt wrote: > On Tue, Feb 14, 2017 at 9:31 PM, Jan Blunck 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. to coexist with >>> 16.11. 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. > >