From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by dpdk.org (Postfix) with ESMTP id CE81458D4 for ; Fri, 18 Sep 2015 12:39:26 +0200 (CEST) Received: from 1.general.rbasak.uk.vpn ([10.172.195.6] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1Zct4f-0003fE-QK; Fri, 18 Sep 2015 10:39:25 +0000 Date: Fri, 18 Sep 2015 11:39:25 +0100 From: Robie Basak To: Thomas Monjalon Message-ID: <20150918103924.GA29184@mal.justgohome.co.uk> References: <20150902134900.GO467@mal.justgohome.co.uk> <4202381.KjbOiZhtub@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4202381.KjbOiZhtub@xps13> Cc: dev@dpdk.org, Stefan Bader Subject: Re: [dpdk-dev] libdpdk upstream changes for ecosystem best practices X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 10:39:26 -0000 Hi Thomas, On Wed, Sep 02, 2015 at 04:18:33PM +0200, Thomas Monjalon wrote: > > First, it would be easier for us to ship a single binary package that > > ships a single shared library to cover all of DPDK that library > > consumers might need, rather than having it split up as you do. I > > understand the build system is capable of doing this already, but what > > we don’t have is a well defined soname and sover (currently > > parameterized in the build) for ABI compatibility purposes. As a binary > > No it is now fixed: > http://dpdk.org/browse/dpdk/commit/?id=c3ce2ad3548 It's great that the name "dpdk" is pinned down - thanks. But we need to define the sover also, and make sure it is bumped when the ABI changes. AIUI the build currently produces no sover - is this correct? We'll use a sover of 0 in our packaging for now, unless you object. Then we'll be able to move up to whatever you do when it is well-defined. > > So that we can get DPDK packaging into Ubuntu immediately, please could > > we agree to define (and burn) libdpdk.so.0 to be the ABI that builds > > with upstream release 2.0.0 when built with the native-linuxapp-gcc > > template options plus the following changes: > > CONFIG_RTE_MACHINE=”default” > > CONFIG_RTE_APP_TEST=n > > CONFIG_LIBRTE_VHOST=y > > CONFIG_RTE_EAL_IGB_UIO=n > > CONFIG_RTE_LIBRTE_KNI=n > > CONFIG_RTE_BUILD_COMBINE_LIBS=y > > CONFIG_RTE_BUILD_SHARED_LIB=y > > I feel this configuration is the responsibility of the distribution. > What do you expect to have in the source project? I just wanted to make it clear what we were doing in case changing build configuration parameters resulted in a different ABI. If this isn't the case, then that's fine - it is solely the consider of the distribution as to what build parameters we pick. > > The combined library would be placed into /usr/lib/$(ARCH)-linux-gnu/ > > where it can be found without modification to the library search path. > > We want to ship it like this in Ubuntu anyway, but I’d prefer upstream > > to have defined it as such since then we’ll have a proper definition of > > the ABI that can be shared across distributions and other consumers any > > time ABI compatibility is expected. > > You mean you target ABI compatibility between Linux distributons? > But other libraries could have different versions so you would be lucky > to have a binary application finding the same dependencies. In theory we do get ABI compatibility between distributions. Finding the dependencies is a separate issue; but if the right binaries were installed, there would be no conflicts in finding shared libraries across binaries from different distributions if the ABI is managed right. But that isn't directly our target. It's still useful to us to have this done right. It makes ABI transitions in the distribution (coordinating updates to libraries and their consumers concurrently) possible without breaking things in the middle. It means that when we talk to upstreams (both libraries and their consumers) then we're speaking the same language as other distributions, and patches apply to them all without each distribution having to kludge things independently. And it gives us options when different library consumers require different ABI versions since we can concurrently install two different ABIs of the same library (although we prefer to avoid that). > > Though not strictly part of a shared library ABI, I also propose some > > build-related upstream changes at API level below, that I’d like to also > > ship in the initial Ubuntu packaging of the header files. Clearly you > > cannot make this change in an existing release, but I propose that you > > do this for your next release so all library consumers will see a > > consistent and standard API interface. If you agree to this, then I’d > > also like to ship the Ubuntu package with patches to do the same thing > > in your current release. > > Yes cleanup patches are welcome :) I'm arranging to have someone work on these with you upstream and send you patches, thanks. Robie