From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=iavW+FIMP/3vl3AbzQdXuTM3FNCyxJHVl0SOvCoPTD4=; b=Zk/HF8AlrUj5cHMbaYxujtKLub3TwhQbrLERxNTa9cznDDrYt+6nGlOKCZDNO56Ndz UPkKiBQTY34G+mo5f/c2rOjnI4Da9A6N4f7Z3n0AqLhY/XYg88vM/moyscJ/HsfrOdRU IaqHtQAltvHPpMwrMJJwAqIEgk8L3aGEvluzeNwbmN5x1XBHntjFJ3vYt5aCBbahV+fq /RtTludESCuEdUfiqYM2AD0FajwdfdDuoWYUhBlyBnwtHdrnjX7eAwzsImwLQFKMRr53 fjBo2zos/21GL/jBhfbLZdTvOLaSxVrApKZ7GpEtf/AE+W3PUuKsWUXpuJWwq7ZnpDsW vxdw== X-Gm-Message-State: ALoCoQn/Rce46ezLEFxS2m5Udh7ITk/tWDoFcOCX3tu+WtQLqnIdFXSEwZkp8sMiAnWalP781ccy X-Received: by 10.180.188.12 with SMTP id fw12mr4570658wic.69.1441203654458; Wed, 02 Sep 2015 07:20:54 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id ej5sm32673971wjd.22.2015.09.02.07.20.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Sep 2015 07:20:53 -0700 (PDT) From: Thomas Monjalon To: Robie Basak Date: Wed, 02 Sep 2015 16:18:33 +0200 Message-ID: <4202381.KjbOiZhtub@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20150902134900.GO467@mal.justgohome.co.uk> References: <20150902134900.GO467@mal.justgohome.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Cc: dev@dpdk.org 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: Wed, 02 Sep 2015 14:20:55 -0000 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