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 2400A5952 for ; Wed, 2 Sep 2015 15:49:01 +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 1ZX8PN-0008B9-1C for dev@dpdk.org; Wed, 02 Sep 2015 13:49:01 +0000 Date: Wed, 2 Sep 2015 14:49:00 +0100 From: Robie Basak To: dev@dpdk.org Message-ID: <20150902134900.GO467@mal.justgohome.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: [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 13:49:01 -0000 Hi, We’re looking at packaging DPDK in Ubuntu. We’d like to discuss upstream changes to better integrate DPDK into Linux distributions. Here’s a summary of what we need: 1) Define one library ABI (soname and sover) that we can use instead of the split build. 2) Fix #includes so we don't have to include config.h 3) Put headers into /usr/include/dpdk instead of /usr/include You can see our current packaging progress at https://git.launchpad.net/~ubuntu-server/dpdk/log/?h=ubuntu-wily and a test PPA at https://launchpad.net/~smb/+archive/ubuntu/dpdk/ 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 distribution, this is something that we’d expect upstream to define, since normally we expect to achieve binary compatibility across all distributions at this level in the stack. So I have the following requests: 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 CONFIG_RTE_LIBNAME=”dpdk” 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. 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. Right now, I understand that library consumers need to either: 1) use the upstream-provided build system (.mk files etc); or 2) otherwise make 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 this case I’d expect it to be conditionally included automatically as part of the API, for example by #include’ing 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. That brings me to paths. To avoid polluting the /usr/include namespace, I’d expect either a single /usr/include/dpdk.h, or everything inside /usr/include/dpdk/, or both. Then library consumers would #include 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’t have to be concerned about paths, configuration or build systems. This would then match every other shared library we package. Does this sound reasonable to you? Is this a change you will accept? Thanks, Robie