From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: libdpdk upstream changes for ecosystem best practices Date: Wed, 02 Sep 2015 16:18:33 +0200 Message-ID: <4202381.KjbOiZhtub@xps13> References: <20150902134900.GO467@mal.justgohome.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org To: Robie Basak Return-path: Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id A8BAF5A35 for ; Wed, 2 Sep 2015 16:20:54 +0200 (CEST) Received: by wibz8 with SMTP id z8so67838216wib.1 for ; Wed, 02 Sep 2015 07:20:54 -0700 (PDT) In-Reply-To: <20150902134900.GO467@mal.justgohome.co.uk> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi, 2015-09-02 14:49, Robie Basak: > Hi, >=20 > We=E2=80=99re looking at packaging DPDK in Ubuntu. We=E2=80=99d like = to discuss upstream Nice > changes to better integrate DPDK into Linux distributions. Here=E2=80= =99s a > summary of what we need: >=20 > 1) Define one library ABI (soname and sover) that we can use instead= of the > split build. >=20 > 2) Fix #includes so we don't have to include config.h >=20 > 3) Put headers into /usr/include/dpdk instead of /usr/include >=20 > You can see our current packaging progress at > https://git.launchpad.net/~ubuntu-server/dpdk/log/?h=3Dubuntu-wily an= d a Thanks for sharing > test PPA at https://launchpad.net/~smb/+archive/ubuntu/dpdk/ >=20 > 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 wha= t > we don=E2=80=99t have is a well defined soname and sover (currently > parameterized in the build) for ABI compatibility purposes. As a bina= ry No it is now fixed: =09http://dpdk.org/browse/dpdk/commit/?id=3Dc3ce2ad3548 > distribution, this is something that we=E2=80=99d expect upstream to = define, > since normally we expect to achieve binary compatibility across all > distributions at this level in the stack. >=20 > So I have the following requests: >=20 > So that we can get DPDK packaging into Ubuntu immediately, please cou= ld > 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=3D=E2=80=9Ddefault=E2=80=9D > CONFIG_RTE_APP_TEST=3Dn > CONFIG_LIBRTE_VHOST=3Dy > CONFIG_RTE_EAL_IGB_UIO=3Dn > CONFIG_RTE_LIBRTE_KNI=3Dn > CONFIG_RTE_BUILD_COMBINE_LIBS=3Dy > CONFIG_RTE_BUILD_SHARED_LIB=3Dy I feel this configuration is the responsibility of the distribution. What do you expect to have in the source project? > CONFIG_RTE_LIBNAME=3D=E2=80=9Ddpdk=E2=80=9D not exist anymore > 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=E2=80=99d prefer= upstream > to have defined it as such since then we=E2=80=99ll have a proper def= inition of > the ABI that can be shared across distributions and other consumers a= ny > 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. > Though not strictly part of a shared library ABI, I also propose some= > build-related upstream changes at API level below, that I=E2=80=99d l= ike 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 yo= u > 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=E2= =80=99d > also like to ship the Ubuntu package with patches to do the same thin= g > in your current release. Yes cleanup patches are welcome :) > Right now, I understand that library consumers need to either: 1) use= > the upstream-provided build system (.mk files etc); or 2) otherwise m= ake > sure to include rte_config.h by specifying it as an extra CPPFLAGS > parameter as the upstream API documentation does not require its > inclusion use in source files. This is problematic because somebody > writing against multiple libraries should just expect to #include the= > API-defined headers and link simply with -l for the build to work. It= is > common to have a config.h type file generated at build time, but in t= his > case I=E2=80=99d expect it to be conditionally included automatically= as part of > the API, for example by #include=E2=80=99ing it in any file the API _= does_ > define that library users must include. To fix this, I propose to > #include in every header file that library users = may > #include according to the API. >=20 > That brings me to paths. To avoid polluting the /usr/include namespac= e, > I=E2=80=99d expect either a single /usr/include/dpdk.h, or everything= inside > /usr/include/dpdk/, or both. Then library consumers would #include The second option seems more reasonable. > combinations of and as required, our packaging > could install into these directories without stealing any other part = of > the shared filesystem namespace, and library users wouldn=E2=80=99t h= ave to be > concerned about paths, configuration or build systems. This would the= n > match every other shared library we package. Does this sound reasonab= le > to you? Is this a change you will accept? Yes there is clearly a namespace issue in DPDK. I would add that libethdev should be librte_ethdev. > Thanks, Thanks for suggesting