Hi, 2015-09-02 14:49, Robie Basak: > Hi, > > We?re looking at packaging DPDK in Ubuntu. We?d like to discuss upstream
Nice > 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 Thanks for sharing > 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 No it is now fixed: http://dpdk.org/browse/dpdk/commit/?id=c3ce2ad3548 > 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 I feel this configuration is the responsibility of the distribution. What do you expect to have in the source project? > CONFIG_RTE_LIBNAME=?dpdk? 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?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. > 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 :) > 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 <dpdk/rte_config.h> 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 The second option seems more reasonable. > combinations of <dpdk.h> and <dpdk/foo.h> 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? Yes there is clearly a namespace issue in DPDK. I would add that libethdev should be librte_ethdev. > Thanks, Thanks for suggesting
