* [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
@ 2016-08-22 18:13 Jason Gunthorpe
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
Hello Everyone,
Here is the patch series for the consolidation. This is based on the special
merge commit created by the buildlib/make-merge.py script. See my prior
message (http://www.spinics.net/lists/linux-rdma/msg39026.html) for details.
The first 7 patches change/fix various things in the original packages to
build consistently, patch 8 has cmake and all the auto* co-exist, and can be
used to do build compares (see buildlib/compare-build.py)
The next batch of patches removes the old build stuff, packaging, merges
COPYING files and lightly simplifies the directory structure.
https://github.com/jgunthorpe/rdma-plumbing
This has been rebased since my last posting with feedback from Steve.
The following 15 repositories were pulled together.
libcxgb3 git://git.openfabrics.org/~swise/libcxgb3.git 0de0392268af3a657b329874b63b6ee827109508
libcxgb4 git://git.openfabrics.org/~swise/libcxgb4.git 15d3253dc814da28e2b93ed02a8e9a96d97f20ae
libhfi1verbs https://github.com/01org/opa-libhfi1verbs.git 377b68888a0b885fc2a44ddf7a2ec33f2fcf217b
libi40iw git://git.openfabrics.org/~tnikolova/libi40iw/.git 9d35609f79d6a235e23182e9ceadf3605b2682da
libibcm git://git.openfabrics.org/~shefty/libibcm.git b04920e8bfe0689a2fe67815321dcf646fd48a7e
libibumad git://git.openfabrics.org/~halr/libibumad.git ecda3a56b18c6a2845f3d966f8b8061941f5d447
libibverbs git://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git 0be978ea2bfaf203c35334b090bddb280de62611
libipathverbs https://github.com/01org/libipathverbs.git 8291d485f3a5544b43974e7be88f3646f35ae07c
libmlx4 git://git.openfabrics.org/~yishaih/libmlx4.git 162f948c4e04753a15cfb7afcdf6219dbe0bc31e
libmlx5 git://git.openfabrics.org/~yishaih/libmlx5.git f23f9aa7b9033cd8ebbd58d67d65e9b81d0525fa
libmthca git://git.kernel.org/pub/scm/libs/infiniband/libmthca.git 6f4dd7451ddef120247e13fa6cb8e1df69c3ddf9
libnes git://git.openfabrics.org/~tnikolova/libnes/.git 7dc7cf2474612ec909bff251096ca2aefa9cddf1
libocrdma git://git.openfabrics.org/~emulex/libocrdma.git 41f6bbb3fe8129678c233da439d872b3fe9f75dc
librdmacm git://git.openfabrics.org/~shefty/librdmacm.git 032bbe60ad32d59004447e03061a9f6d632cc55f
librxe https://github.com/SoftRoCE/librxe-dev.git 227e3c49b6e423c066e1e1887fe30c8261f63cbd
Steve suggests that iwpm be included as well, which makes sense..
My hope is that Doug will step up as the unified maintainer, with a process
similar to the kernel. Most of the libraries are unchanging/unmaintained/dead.
Jason Gunthorpe (15):
Fix bogus executable file permissions
umad: Include umad.h in the canonical way
rdmacm: Control symbol export from librspreload
ibcm: Actually use the version script when linking
Include pthreads in the provider libraries
Be explicit about _GNU_SOURCE
hfi/ipath: Use the name of the provider for the .driver file
Unified CMake build system
Support obsolete cmake from 2013
Remove the auto* based build systems
Remove the ChangeLog files
Combine COPYING files
Consolidate the .gitignore files
Move providers into providers/
Add a MAINTAINERS file
.gitignore | 29 +
CMakeLists.txt | 230 +
COPYING | 6 +
COPYING.BSD | 26 +
libnes/gpl-2.0.txt => COPYING.GPL2 | 14 +-
MAINTAINERS | 81 +
README.md | 69 +
buildlib/FindLDSymVer.cmake | 41 +
buildlib/RDMA_BuildType.cmake | 31 +
buildlib/RDMA_DoFixup.cmake | 25 +
buildlib/RDMA_EnableCStd.cmake | 23 +
buildlib/config.h.in | 29 +
buildlib/fixup-include/rdma-rdma_user_rxe.h | 144 +
buildlib/fixup-include/valgrind-memcheck.h | 5 +
buildlib/provider.map | 6 +
buildlib/publish_headers.cmake | 20 +
buildlib/rdma_functions.cmake | 243 +
libcxgb3/ChangeLog | 791 -
libcxgb3/Makefile.am | 27 -
libcxgb3/autogen.sh | 8 -
libcxgb3/config/.gitignore | 0
libcxgb3/configure.in | 67 -
libcxgb3/cxgb3.driver | 1 -
libcxgb3/libcxgb3.spec.in | 55 -
libcxgb3/src/iwch.map | 6 -
libcxgb4/COPYING | 29 -
libcxgb4/ChangeLog | 1133 --
libcxgb4/Makefile.am | 27 -
libcxgb4/autogen.sh | 8 -
libcxgb4/config/config.guess | 1439 --
libcxgb4/config/config.sub | 1811 ---
libcxgb4/config/depcomp | 530 -
libcxgb4/config/install-sh | 323 -
libcxgb4/configure.in | 67 -
libcxgb4/cxgb4.driver | 1 -
libcxgb4/libcxgb4.spec.in | 55 -
libcxgb4/src/cxgb4.map | 6 -
libhfi1verbs/.gitignore | 18 -
libhfi1verbs/Makefile.am | 83 -
libhfi1verbs/autogen.sh | 64 -
libhfi1verbs/configure.in | 124 -
libhfi1verbs/hfi1.driver | 1 -
libhfi1verbs/libhfi1verbs.spec.in | 111 -
libhfi1verbs/makefile | 93 -
libhfi1verbs/makesrpm.sh | 15 -
libhfi1verbs/src/hfiverbs.map | 4 -
libi40iw/COPYING | 372 -
libi40iw/Makefile.am | 26 -
libi40iw/configure.ac | 72 -
libi40iw/i40iw.driver | 1 -
libi40iw/libi40iw.spec.in | 72 -
libi40iw/src/i40iw.map | 39 -
libibcm/COPYING | 378 -
libibcm/ChangeLog | 0
libibcm/Makefile.am | 35 -
libibcm/autogen.sh | 9 -
libibcm/configure.in | 72 -
libibcm/examples/CMakeLists.txt | 2 +
libibcm/src/CMakeLists.txt | 9 +
libibcm/src/cm.c | 2 +-
libibumad/COPYING | 377 -
libibumad/ChangeLog | 94 -
libibumad/Makefile.am | 75 -
libibumad/autogen.sh | 11 -
libibumad/configure.in | 72 -
libibumad/man/CMakeLists.txt | 42 +
libibumad/src/CMakeLists.txt | 14 +
libibumad/src/sysfs.c | 3 -
libibumad/src/umad.c | 2 +-
libibumad/tests/CMakeLists.txt | 5 +
libibumad/tests/umad_reg2_compat.c | 2 +-
libibumad/tests/umad_register2.c | 2 +-
libibverbs/.gitignore | 24 -
libibverbs/COPYING | 378 -
libibverbs/ChangeLog | 583 -
libibverbs/Makefile.am | 126 -
libibverbs/autogen.sh | 4 -
libibverbs/config/.gitignore | 8 -
libibverbs/configure.ac | 125 -
libibverbs/examples/.gitignore | 10 -
libibverbs/examples/CMakeLists.txt | 29 +
libibverbs/examples/asyncwatch.c | 2 +-
libibverbs/examples/rc_pingpong.c | 2 +-
libibverbs/examples/srq_pingpong.c | 2 +-
libibverbs/examples/uc_pingpong.c | 2 +-
libibverbs/examples/ud_pingpong.c | 2 +-
libibverbs/examples/xsrq_pingpong.c | 2 +-
libibverbs/man/CMakeLists.txt | 78 +
libibverbs/src/.gitignore | 3 -
libibverbs/src/CMakeLists.txt | 34 +
libibverbs/src/device.c | 2 +-
libibverbs/src/init.c | 2 +-
libibverbs/src/sysfs.c | 2 +-
libipathverbs/.gitignore | 22 -
libipathverbs/Makefile.am | 79 -
libipathverbs/autogen.sh | 43 -
libipathverbs/configure.in | 118 -
libipathverbs/ipath.driver | 1 -
libipathverbs/libipathverbs.spec.in | 104 -
libipathverbs/src/ipathverbs.map | 4 -
libmlx4/.gitignore | 17 -
libmlx4/COPYING | 378 -
libmlx4/Makefile.am | 19 -
libmlx4/autogen.sh | 4 -
libmlx4/config/.gitignore | 8 -
libmlx4/configure.ac | 94 -
libmlx4/debian/changelog | 73 -
libmlx4/debian/compat | 1 -
libmlx4/debian/control | 47 -
libmlx4/debian/copyright | 43 -
libmlx4/debian/libmlx4-1.install | 2 -
libmlx4/debian/libmlx4-dev.install | 1 -
.../debian/patches/driver-plugin-directory.patch | 10 -
libmlx4/debian/patches/series | 1 -
libmlx4/debian/rules | 10 -
libmlx4/debian/source/format | 1 -
libmlx4/debian/watch | 3 -
libmlx4/libmlx4.spec.in | 90 -
libmlx4/mlx4.driver | 1 -
libmlx4/src/.gitignore | 3 -
libmlx4/src/mlx4.map | 5 -
libmlx5/.gitignore | 33 -
libmlx5/COPYING | 378 -
libmlx5/Makefile.am | 27 -
libmlx5/autogen.sh | 7 -
libmlx5/config/.gitignore | 8 -
libmlx5/configure.ac | 105 -
libmlx5/debian/changelog | 18 -
libmlx5/debian/compat | 1 -
libmlx5/debian/control | 47 -
libmlx5/debian/copyright | 43 -
libmlx5/debian/libmlx5-1.install | 2 -
libmlx5/debian/libmlx5-dev.install | 1 -
.../debian/patches/driver-plugin-directory.patch | 10 -
libmlx5/debian/patches/series | 1 -
libmlx5/debian/rules | 10 -
libmlx5/debian/source/format | 1 -
libmlx5/debian/watch | 3 -
libmlx5/libmlx5.spec.in | 60 -
libmlx5/m4/ax_gcc_func_attribute.m4 | 223 -
libmlx5/mlx5.driver | 1 -
libmlx5/src/.gitignore | 3 -
libmlx5/src/mlx5.map | 5 -
libmthca/.gitignore | 17 -
libmthca/COPYING | 378 -
libmthca/ChangeLog | 378 -
libmthca/Makefile.am | 29 -
libmthca/autogen.sh | 8 -
libmthca/config/.gitignore | 8 -
libmthca/configure.in | 80 -
libmthca/debian/changelog | 73 -
libmthca/debian/compat | 1 -
libmthca/debian/control | 48 -
libmthca/debian/copyright | 44 -
libmthca/debian/libmthca-dev.install | 1 -
libmthca/debian/libmthca1.install | 2 -
.../debian/patches/driver-plugin-directory.patch | 10 -
libmthca/debian/patches/series | 1 -
libmthca/debian/rules | 10 -
libmthca/debian/source/format | 1 -
libmthca/debian/watch | 3 -
libmthca/libmthca.spec.in | 97 -
libmthca/mthca.driver | 1 -
libmthca/src/.gitignore | 3 -
libmthca/src/mthca.map | 5 -
libnes/Makefile.am | 26 -
libnes/autogen.sh | 12 -
libnes/config/.gitignore | 0
libnes/configure.in | 72 -
libnes/libnes.spec.in | 107 -
libnes/nes.driver | 1 -
libnes/src/nes.map | 5 -
libocrdma/COPYING | 317 -
libocrdma/Makefile.am | 23 -
libocrdma/autogen.sh | 8 -
libocrdma/config/.gitignore | 8 -
libocrdma/configure.in | 68 -
libocrdma/libocrdma.spec.in | 71 -
libocrdma/ocrdma.driver | 1 -
libocrdma/src/ocrdma.map | 5 -
librdmacm/.gitignore | 64 -
librdmacm/COPYING | 378 -
librdmacm/ChangeLog | 0
librdmacm/Makefile.am | 138 -
librdmacm/autogen.sh | 5 -
librdmacm/configure.ac | 108 -
librdmacm/examples/.gitignore | 23 -
librdmacm/examples/CMakeLists.txt | 43 +
librdmacm/examples/rping.c | 2 +-
librdmacm/man/CMakeLists.txt | 65 +
librdmacm/src/.gitignore | 9 -
librdmacm/src/CMakeLists.txt | 39 +
librdmacm/src/librspreload.map | 33 +
librdmacm/src/preload.c | 6 +-
librdmacm/src/rsocket.c | 2 +-
librxe/AUTHORS | 0
librxe/COPYING | 0
librxe/ChangeLog | 0
librxe/INSTALL | 0
librxe/Makefile.am | 36 -
librxe/Makefile.in | 939 --
librxe/NEWS | 0
librxe/README | 0
librxe/aclocal.m4 | 9390 ------------
librxe/config.h.in | 89 -
librxe/config/config.guess | 1526 --
librxe/config/config.sub | 1658 ---
librxe/config/depcomp | 530 -
librxe/config/install-sh | 519 -
librxe/config/ltmain.sh | 9636 ------------
librxe/config/missing | 360 -
librxe/configure | 14728 -------------------
librxe/configure.in | 75 -
librxe/librxe.spec | 55 -
librxe/librxe.spec.in | 55 -
librxe/rxe.driver | 1 -
librxe/src/rxe.map | 5 -
{libcxgb4 => providers/cxgb3}/AUTHORS | 0
providers/cxgb3/CMakeLists.txt | 6 +
{libcxgb3 => providers/cxgb3}/COPYING | 0
{libcxgb3 => providers/cxgb3}/README | 0
{libcxgb3/src => providers/cxgb3}/cq.c | 0
{libcxgb3/src => providers/cxgb3}/cxio_wr.h | 0
.../src => providers/cxgb3}/firmware_exports.h | 0
{libcxgb3/src => providers/cxgb3}/iwch-abi.h | 0
{libcxgb3/src => providers/cxgb3}/iwch.c | 0
{libcxgb3/src => providers/cxgb3}/iwch.h | 0
{libcxgb3/src => providers/cxgb3}/qp.c | 0
{libcxgb3/src => providers/cxgb3}/verbs.c | 0
{libcxgb3 => providers/cxgb4}/AUTHORS | 0
providers/cxgb4/CMakeLists.txt | 6 +
{libcxgb4 => providers/cxgb4}/README | 0
{libcxgb4/src => providers/cxgb4}/cq.c | 0
{libcxgb4/src => providers/cxgb4}/cxgb4-abi.h | 0
{libcxgb4/src => providers/cxgb4}/dev.c | 0
{libcxgb4/src => providers/cxgb4}/libcxgb4.h | 0
{libcxgb4/src => providers/cxgb4}/qp.c | 0
{libcxgb4/src => providers/cxgb4}/queue.h | 0
{libcxgb4/src => providers/cxgb4}/t4.h | 0
{libcxgb4/src => providers/cxgb4}/t4_chip_type.h | 0
{libcxgb4/src => providers/cxgb4}/t4_pci_id_tbl.h | 0
{libcxgb4/src => providers/cxgb4}/t4_regs.h | 0
{libcxgb4/src => providers/cxgb4}/t4fw_interface.h | 0
{libcxgb4/src => providers/cxgb4}/verbs.c | 0
{libhfi1verbs => providers/hfi1verbs}/AUTHORS | 0
providers/hfi1verbs/CMakeLists.txt | 4 +
{libhfi1verbs => providers/hfi1verbs}/COPYING | 0
{libhfi1verbs => providers/hfi1verbs}/README | 0
.../src => providers/hfi1verbs}/hfi-abi.h | 0
.../src => providers/hfi1verbs}/hfiverbs.c | 0
.../src => providers/hfi1verbs}/hfiverbs.h | 0
{libhfi1verbs/src => providers/hfi1verbs}/verbs.c | 0
{libnes => providers/i40iw}/AUTHORS | 0
providers/i40iw/CMakeLists.txt | 5 +
{libi40iw/src => providers/i40iw}/i40e_devids.h | 0
{libi40iw/src => providers/i40iw}/i40iw-abi.h | 0
{libi40iw/src => providers/i40iw}/i40iw_d.h | 0
{libi40iw/src => providers/i40iw}/i40iw_osdep.h | 0
{libi40iw/src => providers/i40iw}/i40iw_register.h | 0
{libi40iw/src => providers/i40iw}/i40iw_status.h | 0
{libi40iw/src => providers/i40iw}/i40iw_uk.c | 0
{libi40iw/src => providers/i40iw}/i40iw_umain.c | 0
{libi40iw/src => providers/i40iw}/i40iw_umain.h | 0
{libi40iw/src => providers/i40iw}/i40iw_user.h | 0
{libi40iw/src => providers/i40iw}/i40iw_uverbs.c | 0
{libipathverbs => providers/ipathverbs}/AUTHORS | 0
providers/ipathverbs/CMakeLists.txt | 8 +
{libipathverbs => providers/ipathverbs}/COPYING | 0
{libipathverbs => providers/ipathverbs}/README | 0
.../ipathverbs}/dracut_check | 0
.../ipathverbs}/dracut_install | 0
.../ipathverbs}/dracut_kmod | 0
.../src => providers/ipathverbs}/ipath-abi.h | 0
.../src => providers/ipathverbs}/ipathverbs.c | 0
.../src => providers/ipathverbs}/ipathverbs.h | 0
.../ipathverbs}/truescale-serdes.cmds | 0
.../ipathverbs}/truescale.conf | 0
.../src => providers/ipathverbs}/verbs.c | 0
{libmlx4 => providers/mlx4}/AUTHORS | 0
providers/mlx4/CMakeLists.txt | 9 +
{libmlx4 => providers/mlx4}/README | 0
{libmlx4/src => providers/mlx4}/buf.c | 0
{libmlx4/src => providers/mlx4}/cq.c | 0
{libmlx4/src => providers/mlx4}/dbrec.c | 2 +-
{libmlx4/src => providers/mlx4}/doorbell.h | 0
{libmlx4/src => providers/mlx4}/mlx4-abi.h | 0
{libmlx4/src => providers/mlx4}/mlx4.c | 0
{libmlx4/src => providers/mlx4}/mlx4.h | 0
{libmlx4/src => providers/mlx4}/mmio.h | 0
{libmlx4/src => providers/mlx4}/qp.c | 0
{libmlx4/src => providers/mlx4}/srq.c | 0
{libmlx4/src => providers/mlx4}/verbs.c | 0
{libmlx4/src => providers/mlx4}/wqe.h | 0
{libmlx5 => providers/mlx5}/AUTHORS | 0
providers/mlx5/CMakeLists.txt | 9 +
{libmlx5 => providers/mlx5}/README | 0
{libmlx5/src => providers/mlx5}/bitmap.h | 0
{libmlx5/src => providers/mlx5}/buf.c | 0
{libmlx5/src => providers/mlx5}/cq.c | 0
{libmlx5/src => providers/mlx5}/dbrec.c | 3 +-
{libmlx5/src => providers/mlx5}/doorbell.h | 0
{libmlx5/src => providers/mlx5}/list.h | 0
{libmlx5/src => providers/mlx5}/mlx5-abi.h | 0
{libmlx5/src => providers/mlx5}/mlx5.c | 3 +-
{libmlx5/src => providers/mlx5}/mlx5.h | 0
{libmlx5/src => providers/mlx5}/qp.c | 0
{libmlx5/src => providers/mlx5}/srq.c | 0
{libmlx5/src => providers/mlx5}/verbs.c | 0
{libmlx5/src => providers/mlx5}/wqe.h | 0
{libmthca => providers/mthca}/AUTHORS | 0
providers/mthca/CMakeLists.txt | 10 +
{libmthca => providers/mthca}/README | 0
{libmthca/src => providers/mthca}/ah.c | 0
{libmthca/src => providers/mthca}/buf.c | 0
{libmthca/src => providers/mthca}/cq.c | 0
{libmthca/src => providers/mthca}/doorbell.h | 0
{libmthca/src => providers/mthca}/memfree.c | 2 +-
{libmthca/src => providers/mthca}/mthca-abi.h | 0
{libmthca/src => providers/mthca}/mthca.c | 0
{libmthca/src => providers/mthca}/mthca.h | 0
{libmthca/src => providers/mthca}/qp.c | 0
{libmthca/src => providers/mthca}/srq.c | 0
{libmthca/src => providers/mthca}/verbs.c | 0
{libmthca/src => providers/mthca}/wqe.h | 0
{libi40iw => providers/nes}/AUTHORS | 0
providers/nes/CMakeLists.txt | 4 +
{libnes => providers/nes}/COPYING | 0
{libnes/src => providers/nes}/nes-abi.h | 0
{libnes/src => providers/nes}/nes_umain.c | 0
{libnes/src => providers/nes}/nes_umain.h | 0
{libnes/src => providers/nes}/nes_uverbs.c | 0
{libocrdma => providers/ocrdma}/AUTHORS | 0
providers/ocrdma/CMakeLists.txt | 4 +
{libocrdma => providers/ocrdma}/Changelog | 0
{libocrdma => providers/ocrdma}/README | 0
{libocrdma/src => providers/ocrdma}/ocrdma_abi.h | 0
{libocrdma/src => providers/ocrdma}/ocrdma_list.h | 0
{libocrdma/src => providers/ocrdma}/ocrdma_main.c | 0
{libocrdma/src => providers/ocrdma}/ocrdma_main.h | 0
{libocrdma/src => providers/ocrdma}/ocrdma_verbs.c | 0
providers/rxe/CMakeLists.txt | 7 +
{librxe => providers/rxe}/README.md | 0
providers/rxe/man/CMakeLists.txt | 4 +
{librxe => providers/rxe}/man/rxe.7 | 0
{librxe => providers/rxe}/man/rxe_cfg.8 | 0
{librxe/src => providers/rxe}/rxe-abi.h | 0
{librxe/src => providers/rxe}/rxe.c | 0
{librxe/src => providers/rxe}/rxe.h | 0
{librxe => providers/rxe}/rxe_cfg | 0
{librxe/src => providers/rxe}/rxe_queue.h | 0
350 files changed, 1506 insertions(+), 54315 deletions(-)
create mode 100644 .gitignore
create mode 100644 CMakeLists.txt
create mode 100644 COPYING
create mode 100644 COPYING.BSD
rename libnes/gpl-2.0.txt => COPYING.GPL2 (98%)
create mode 100644 MAINTAINERS
create mode 100644 README.md
create mode 100644 buildlib/FindLDSymVer.cmake
create mode 100644 buildlib/RDMA_BuildType.cmake
create mode 100644 buildlib/RDMA_DoFixup.cmake
create mode 100644 buildlib/RDMA_EnableCStd.cmake
create mode 100644 buildlib/config.h.in
create mode 100644 buildlib/fixup-include/rdma-rdma_user_rxe.h
create mode 100644 buildlib/fixup-include/valgrind-memcheck.h
create mode 100644 buildlib/provider.map
create mode 100644 buildlib/publish_headers.cmake
create mode 100644 buildlib/rdma_functions.cmake
delete mode 100644 libcxgb3/ChangeLog
delete mode 100644 libcxgb3/Makefile.am
delete mode 100755 libcxgb3/autogen.sh
delete mode 100644 libcxgb3/config/.gitignore
delete mode 100644 libcxgb3/configure.in
delete mode 100644 libcxgb3/cxgb3.driver
delete mode 100644 libcxgb3/libcxgb3.spec.in
delete mode 100644 libcxgb3/src/iwch.map
delete mode 100644 libcxgb4/COPYING
delete mode 100644 libcxgb4/ChangeLog
delete mode 100644 libcxgb4/Makefile.am
delete mode 100755 libcxgb4/autogen.sh
delete mode 100755 libcxgb4/config/config.guess
delete mode 100755 libcxgb4/config/config.sub
delete mode 100755 libcxgb4/config/depcomp
delete mode 100755 libcxgb4/config/install-sh
delete mode 100644 libcxgb4/configure.in
delete mode 100644 libcxgb4/cxgb4.driver
delete mode 100644 libcxgb4/libcxgb4.spec.in
delete mode 100644 libcxgb4/src/cxgb4.map
delete mode 100644 libhfi1verbs/.gitignore
delete mode 100644 libhfi1verbs/Makefile.am
delete mode 100755 libhfi1verbs/autogen.sh
delete mode 100644 libhfi1verbs/configure.in
delete mode 100644 libhfi1verbs/hfi1.driver
delete mode 100644 libhfi1verbs/libhfi1verbs.spec.in
delete mode 100644 libhfi1verbs/makefile
delete mode 100644 libhfi1verbs/makesrpm.sh
delete mode 100644 libhfi1verbs/src/hfiverbs.map
delete mode 100644 libi40iw/COPYING
delete mode 100644 libi40iw/Makefile.am
delete mode 100644 libi40iw/configure.ac
delete mode 100644 libi40iw/i40iw.driver
delete mode 100644 libi40iw/libi40iw.spec.in
delete mode 100644 libi40iw/src/i40iw.map
delete mode 100644 libibcm/COPYING
delete mode 100644 libibcm/ChangeLog
delete mode 100644 libibcm/Makefile.am
delete mode 100755 libibcm/autogen.sh
delete mode 100644 libibcm/configure.in
create mode 100644 libibcm/examples/CMakeLists.txt
create mode 100644 libibcm/src/CMakeLists.txt
mode change 100755 => 100644 libibcm/src/cm.c
delete mode 100644 libibumad/COPYING
delete mode 100644 libibumad/ChangeLog
delete mode 100644 libibumad/Makefile.am
delete mode 100755 libibumad/autogen.sh
delete mode 100644 libibumad/configure.in
create mode 100644 libibumad/man/CMakeLists.txt
create mode 100644 libibumad/src/CMakeLists.txt
create mode 100644 libibumad/tests/CMakeLists.txt
delete mode 100644 libibverbs/.gitignore
delete mode 100644 libibverbs/COPYING
delete mode 100644 libibverbs/ChangeLog
delete mode 100644 libibverbs/Makefile.am
delete mode 100755 libibverbs/autogen.sh
delete mode 100644 libibverbs/config/.gitignore
delete mode 100644 libibverbs/configure.ac
delete mode 100644 libibverbs/examples/.gitignore
create mode 100644 libibverbs/examples/CMakeLists.txt
create mode 100644 libibverbs/man/CMakeLists.txt
delete mode 100644 libibverbs/src/.gitignore
create mode 100644 libibverbs/src/CMakeLists.txt
delete mode 100644 libipathverbs/.gitignore
delete mode 100644 libipathverbs/Makefile.am
delete mode 100755 libipathverbs/autogen.sh
delete mode 100644 libipathverbs/configure.in
delete mode 100644 libipathverbs/ipath.driver
delete mode 100644 libipathverbs/libipathverbs.spec.in
delete mode 100644 libipathverbs/src/ipathverbs.map
delete mode 100644 libmlx4/.gitignore
delete mode 100644 libmlx4/COPYING
delete mode 100644 libmlx4/Makefile.am
delete mode 100755 libmlx4/autogen.sh
delete mode 100644 libmlx4/config/.gitignore
delete mode 100644 libmlx4/configure.ac
delete mode 100644 libmlx4/debian/changelog
delete mode 100644 libmlx4/debian/compat
delete mode 100644 libmlx4/debian/control
delete mode 100644 libmlx4/debian/copyright
delete mode 100644 libmlx4/debian/libmlx4-1.install
delete mode 100644 libmlx4/debian/libmlx4-dev.install
delete mode 100644 libmlx4/debian/patches/driver-plugin-directory.patch
delete mode 100644 libmlx4/debian/patches/series
delete mode 100755 libmlx4/debian/rules
delete mode 100644 libmlx4/debian/source/format
delete mode 100644 libmlx4/debian/watch
delete mode 100644 libmlx4/libmlx4.spec.in
delete mode 100644 libmlx4/mlx4.driver
delete mode 100644 libmlx4/src/.gitignore
delete mode 100644 libmlx4/src/mlx4.map
delete mode 100644 libmlx5/.gitignore
delete mode 100644 libmlx5/COPYING
delete mode 100644 libmlx5/Makefile.am
delete mode 100755 libmlx5/autogen.sh
delete mode 100644 libmlx5/config/.gitignore
delete mode 100644 libmlx5/configure.ac
delete mode 100644 libmlx5/debian/changelog
delete mode 100644 libmlx5/debian/compat
delete mode 100644 libmlx5/debian/control
delete mode 100644 libmlx5/debian/copyright
delete mode 100644 libmlx5/debian/libmlx5-1.install
delete mode 100644 libmlx5/debian/libmlx5-dev.install
delete mode 100644 libmlx5/debian/patches/driver-plugin-directory.patch
delete mode 100644 libmlx5/debian/patches/series
delete mode 100755 libmlx5/debian/rules
delete mode 100644 libmlx5/debian/source/format
delete mode 100644 libmlx5/debian/watch
delete mode 100644 libmlx5/libmlx5.spec.in
delete mode 100644 libmlx5/m4/ax_gcc_func_attribute.m4
delete mode 100644 libmlx5/mlx5.driver
delete mode 100644 libmlx5/src/.gitignore
delete mode 100644 libmlx5/src/mlx5.map
delete mode 100644 libmthca/.gitignore
delete mode 100644 libmthca/COPYING
delete mode 100644 libmthca/ChangeLog
delete mode 100644 libmthca/Makefile.am
delete mode 100755 libmthca/autogen.sh
delete mode 100644 libmthca/config/.gitignore
delete mode 100644 libmthca/configure.in
delete mode 100644 libmthca/debian/changelog
delete mode 100644 libmthca/debian/compat
delete mode 100644 libmthca/debian/control
delete mode 100644 libmthca/debian/copyright
delete mode 100644 libmthca/debian/libmthca-dev.install
delete mode 100644 libmthca/debian/libmthca1.install
delete mode 100644 libmthca/debian/patches/driver-plugin-directory.patch
delete mode 100644 libmthca/debian/patches/series
delete mode 100755 libmthca/debian/rules
delete mode 100644 libmthca/debian/source/format
delete mode 100644 libmthca/debian/watch
delete mode 100644 libmthca/libmthca.spec.in
delete mode 100644 libmthca/mthca.driver
delete mode 100644 libmthca/src/.gitignore
delete mode 100644 libmthca/src/mthca.map
delete mode 100644 libnes/Makefile.am
delete mode 100755 libnes/autogen.sh
delete mode 100644 libnes/config/.gitignore
delete mode 100644 libnes/configure.in
delete mode 100644 libnes/libnes.spec.in
delete mode 100644 libnes/nes.driver
delete mode 100644 libnes/src/nes.map
delete mode 100644 libocrdma/COPYING
delete mode 100644 libocrdma/Makefile.am
delete mode 100644 libocrdma/autogen.sh
delete mode 100644 libocrdma/config/.gitignore
delete mode 100644 libocrdma/configure.in
delete mode 100644 libocrdma/libocrdma.spec.in
delete mode 100644 libocrdma/ocrdma.driver
delete mode 100644 libocrdma/src/ocrdma.map
delete mode 100644 librdmacm/.gitignore
delete mode 100644 librdmacm/COPYING
delete mode 100644 librdmacm/ChangeLog
delete mode 100644 librdmacm/Makefile.am
delete mode 100755 librdmacm/autogen.sh
delete mode 100644 librdmacm/configure.ac
delete mode 100644 librdmacm/examples/.gitignore
create mode 100644 librdmacm/examples/CMakeLists.txt
create mode 100644 librdmacm/man/CMakeLists.txt
delete mode 100644 librdmacm/src/.gitignore
create mode 100644 librdmacm/src/CMakeLists.txt
create mode 100644 librdmacm/src/librspreload.map
delete mode 100644 librxe/AUTHORS
delete mode 100644 librxe/COPYING
delete mode 100644 librxe/ChangeLog
delete mode 100644 librxe/INSTALL
delete mode 100644 librxe/Makefile.am
delete mode 100644 librxe/Makefile.in
delete mode 100644 librxe/NEWS
delete mode 100644 librxe/README
delete mode 100644 librxe/aclocal.m4
delete mode 100644 librxe/config.h.in
delete mode 100755 librxe/config/config.guess
delete mode 100755 librxe/config/config.sub
delete mode 100755 librxe/config/depcomp
delete mode 100755 librxe/config/install-sh
delete mode 100755 librxe/config/ltmain.sh
delete mode 100755 librxe/config/missing
delete mode 100755 librxe/configure
delete mode 100644 librxe/configure.in
delete mode 100644 librxe/librxe.spec
delete mode 100644 librxe/librxe.spec.in
delete mode 100644 librxe/rxe.driver
delete mode 100644 librxe/src/rxe.map
rename {libcxgb4 => providers/cxgb3}/AUTHORS (100%)
create mode 100644 providers/cxgb3/CMakeLists.txt
rename {libcxgb3 => providers/cxgb3}/COPYING (100%)
rename {libcxgb3 => providers/cxgb3}/README (100%)
rename {libcxgb3/src => providers/cxgb3}/cq.c (100%)
rename {libcxgb3/src => providers/cxgb3}/cxio_wr.h (100%)
rename {libcxgb3/src => providers/cxgb3}/firmware_exports.h (100%)
rename {libcxgb3/src => providers/cxgb3}/iwch-abi.h (100%)
rename {libcxgb3/src => providers/cxgb3}/iwch.c (100%)
rename {libcxgb3/src => providers/cxgb3}/iwch.h (100%)
rename {libcxgb3/src => providers/cxgb3}/qp.c (100%)
rename {libcxgb3/src => providers/cxgb3}/verbs.c (100%)
rename {libcxgb3 => providers/cxgb4}/AUTHORS (100%)
create mode 100644 providers/cxgb4/CMakeLists.txt
rename {libcxgb4 => providers/cxgb4}/README (100%)
rename {libcxgb4/src => providers/cxgb4}/cq.c (100%)
rename {libcxgb4/src => providers/cxgb4}/cxgb4-abi.h (100%)
rename {libcxgb4/src => providers/cxgb4}/dev.c (100%)
rename {libcxgb4/src => providers/cxgb4}/libcxgb4.h (100%)
rename {libcxgb4/src => providers/cxgb4}/qp.c (100%)
rename {libcxgb4/src => providers/cxgb4}/queue.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4_chip_type.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4_pci_id_tbl.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4_regs.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4fw_interface.h (100%)
rename {libcxgb4/src => providers/cxgb4}/verbs.c (100%)
rename {libhfi1verbs => providers/hfi1verbs}/AUTHORS (100%)
create mode 100644 providers/hfi1verbs/CMakeLists.txt
rename {libhfi1verbs => providers/hfi1verbs}/COPYING (100%)
rename {libhfi1verbs => providers/hfi1verbs}/README (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/hfi-abi.h (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/hfiverbs.c (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/hfiverbs.h (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/verbs.c (100%)
rename {libnes => providers/i40iw}/AUTHORS (100%)
create mode 100644 providers/i40iw/CMakeLists.txt
rename {libi40iw/src => providers/i40iw}/i40e_devids.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw-abi.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_d.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_osdep.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_register.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_status.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_uk.c (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_umain.c (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_umain.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_user.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_uverbs.c (100%)
rename {libipathverbs => providers/ipathverbs}/AUTHORS (100%)
create mode 100644 providers/ipathverbs/CMakeLists.txt
rename {libipathverbs => providers/ipathverbs}/COPYING (100%)
rename {libipathverbs => providers/ipathverbs}/README (100%)
rename {libipathverbs => providers/ipathverbs}/dracut_check (100%)
rename {libipathverbs => providers/ipathverbs}/dracut_install (100%)
rename {libipathverbs => providers/ipathverbs}/dracut_kmod (100%)
rename {libipathverbs/src => providers/ipathverbs}/ipath-abi.h (100%)
rename {libipathverbs/src => providers/ipathverbs}/ipathverbs.c (100%)
rename {libipathverbs/src => providers/ipathverbs}/ipathverbs.h (100%)
rename {libipathverbs => providers/ipathverbs}/truescale-serdes.cmds (100%)
mode change 100644 => 100755
rename {libipathverbs => providers/ipathverbs}/truescale.conf (100%)
rename {libipathverbs/src => providers/ipathverbs}/verbs.c (100%)
rename {libmlx4 => providers/mlx4}/AUTHORS (100%)
create mode 100644 providers/mlx4/CMakeLists.txt
rename {libmlx4 => providers/mlx4}/README (100%)
rename {libmlx4/src => providers/mlx4}/buf.c (100%)
rename {libmlx4/src => providers/mlx4}/cq.c (100%)
rename {libmlx4/src => providers/mlx4}/dbrec.c (99%)
rename {libmlx4/src => providers/mlx4}/doorbell.h (100%)
rename {libmlx4/src => providers/mlx4}/mlx4-abi.h (100%)
rename {libmlx4/src => providers/mlx4}/mlx4.c (100%)
rename {libmlx4/src => providers/mlx4}/mlx4.h (100%)
rename {libmlx4/src => providers/mlx4}/mmio.h (100%)
rename {libmlx4/src => providers/mlx4}/qp.c (100%)
rename {libmlx4/src => providers/mlx4}/srq.c (100%)
rename {libmlx4/src => providers/mlx4}/verbs.c (100%)
rename {libmlx4/src => providers/mlx4}/wqe.h (100%)
rename {libmlx5 => providers/mlx5}/AUTHORS (100%)
create mode 100644 providers/mlx5/CMakeLists.txt
rename {libmlx5 => providers/mlx5}/README (100%)
rename {libmlx5/src => providers/mlx5}/bitmap.h (100%)
rename {libmlx5/src => providers/mlx5}/buf.c (100%)
rename {libmlx5/src => providers/mlx5}/cq.c (100%)
rename {libmlx5/src => providers/mlx5}/dbrec.c (99%)
rename {libmlx5/src => providers/mlx5}/doorbell.h (100%)
rename {libmlx5/src => providers/mlx5}/list.h (100%)
rename {libmlx5/src => providers/mlx5}/mlx5-abi.h (100%)
rename {libmlx5/src => providers/mlx5}/mlx5.c (99%)
rename {libmlx5/src => providers/mlx5}/mlx5.h (100%)
rename {libmlx5/src => providers/mlx5}/qp.c (100%)
rename {libmlx5/src => providers/mlx5}/srq.c (100%)
rename {libmlx5/src => providers/mlx5}/verbs.c (100%)
rename {libmlx5/src => providers/mlx5}/wqe.h (100%)
rename {libmthca => providers/mthca}/AUTHORS (100%)
create mode 100644 providers/mthca/CMakeLists.txt
rename {libmthca => providers/mthca}/README (100%)
rename {libmthca/src => providers/mthca}/ah.c (100%)
rename {libmthca/src => providers/mthca}/buf.c (100%)
rename {libmthca/src => providers/mthca}/cq.c (100%)
rename {libmthca/src => providers/mthca}/doorbell.h (100%)
rename {libmthca/src => providers/mthca}/memfree.c (99%)
rename {libmthca/src => providers/mthca}/mthca-abi.h (100%)
rename {libmthca/src => providers/mthca}/mthca.c (100%)
rename {libmthca/src => providers/mthca}/mthca.h (100%)
rename {libmthca/src => providers/mthca}/qp.c (100%)
rename {libmthca/src => providers/mthca}/srq.c (100%)
rename {libmthca/src => providers/mthca}/verbs.c (100%)
rename {libmthca/src => providers/mthca}/wqe.h (100%)
rename {libi40iw => providers/nes}/AUTHORS (100%)
create mode 100644 providers/nes/CMakeLists.txt
rename {libnes => providers/nes}/COPYING (100%)
rename {libnes/src => providers/nes}/nes-abi.h (100%)
rename {libnes/src => providers/nes}/nes_umain.c (100%)
rename {libnes/src => providers/nes}/nes_umain.h (100%)
rename {libnes/src => providers/nes}/nes_uverbs.c (100%)
rename {libocrdma => providers/ocrdma}/AUTHORS (100%)
create mode 100644 providers/ocrdma/CMakeLists.txt
rename {libocrdma => providers/ocrdma}/Changelog (100%)
rename {libocrdma => providers/ocrdma}/README (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_abi.h (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_list.h (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_main.c (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_main.h (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_verbs.c (100%)
create mode 100644 providers/rxe/CMakeLists.txt
rename {librxe => providers/rxe}/README.md (100%)
create mode 100644 providers/rxe/man/CMakeLists.txt
rename {librxe => providers/rxe}/man/rxe.7 (100%)
rename {librxe => providers/rxe}/man/rxe_cfg.8 (100%)
rename {librxe/src => providers/rxe}/rxe-abi.h (100%)
rename {librxe/src => providers/rxe}/rxe.c (100%)
rename {librxe/src => providers/rxe}/rxe.h (100%)
rename {librxe => providers/rxe}/rxe_cfg (100%)
rename {librxe/src => providers/rxe}/rxe_queue.h (100%)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* [RFCv2 01/15] Fix bogus executable file permissions
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 02/15] umad: Include umad.h in the canonical way Jason Gunthorpe
` (17 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
libibcm/src/cm.c | 0
libipathverbs/truescale-serdes.cmds | 0
2 files changed, 0 insertions(+), 0 deletions(-)
mode change 100755 => 100644 libibcm/src/cm.c
mode change 100644 => 100755 libipathverbs/truescale-serdes.cmds
diff --git a/libibcm/src/cm.c b/libibcm/src/cm.c
old mode 100755
new mode 100644
diff --git a/libipathverbs/truescale-serdes.cmds b/libipathverbs/truescale-serdes.cmds
old mode 100644
new mode 100755
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* [RFCv2 02/15] umad: Include umad.h in the canonical way
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-22 18:13 ` [RFCv2 01/15] Fix bogus executable file permissions Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 03/15] rdmacm: Control symbol export from librspreload Jason Gunthorpe
` (16 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
Should always be:
#include <infiniband/umad.h>
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
libibumad/src/umad.c | 2 +-
libibumad/tests/umad_reg2_compat.c | 2 +-
libibumad/tests/umad_register2.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libibumad/src/umad.c b/libibumad/src/umad.c
index 7b799f9512bb..a7879d385466 100644
--- a/libibumad/src/umad.c
+++ b/libibumad/src/umad.c
@@ -50,7 +50,7 @@
#include <ctype.h>
#include <inttypes.h>
-#include "umad.h"
+#include <infiniband/umad.h>
#define IB_OPENIB_OUI (0x001405)
diff --git a/libibumad/tests/umad_reg2_compat.c b/libibumad/tests/umad_reg2_compat.c
index 4f433062b57d..413a3bec6d58 100644
--- a/libibumad/tests/umad_reg2_compat.c
+++ b/libibumad/tests/umad_reg2_compat.c
@@ -39,7 +39,7 @@
#include <stdio.h>
#include <inttypes.h>
-#include "umad.h"
+#include <infiniband/umad.h>
#define UNLIKELY_MGMT_CLASS 0x2F
#define UNLIKELY_RMPP_MGMT_CLASS 0x4F
diff --git a/libibumad/tests/umad_register2.c b/libibumad/tests/umad_register2.c
index 93692ee7a856..c2d7846038bd 100644
--- a/libibumad/tests/umad_register2.c
+++ b/libibumad/tests/umad_register2.c
@@ -41,7 +41,7 @@
#include <errno.h>
#include <sys/ioctl.h>
-#include "umad.h"
+#include <infiniband/umad.h>
#define UNLIKELY_MGMT_CLASS 0x2F
#define UNLIKELY_RMPP_MGMT_CLASS 0x4F
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 03/15] rdmacm: Control symbol export from librspreload
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-22 18:13 ` [RFCv2 01/15] Fix bogus executable file permissions Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 02/15] umad: Include umad.h in the canonical way Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 04/15] ibcm: Actually use the version script when linking Jason Gunthorpe
` (15 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
Since librspreload is a LD_PRELOAD library it should only export
symbols it intends to override. The following internal symbols were
leaking out:
getenv_options
idm_clear
idm_set
idx_insert
idx_remove
idx_replace
set_rsocket_options
The simplest way to fix this is with a map file.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
librdmacm/Makefile.am | 5 ++++-
librdmacm/src/librspreload.map | 33 +++++++++++++++++++++++++++++++++
librdmacm/src/preload.c | 4 ++--
3 files changed, 39 insertions(+), 3 deletions(-)
create mode 100644 librdmacm/src/librspreload.map
diff --git a/librdmacm/Makefile.am b/librdmacm/Makefile.am
index bf721345f68d..fa82d801a4dd 100644
--- a/librdmacm/Makefile.am
+++ b/librdmacm/Makefile.am
@@ -23,7 +23,10 @@ src_librdmacm_la_LDFLAGS = -version-info 1 -export-dynamic \
src_librdmacm_la_DEPENDENCIES = $(srcdir)/src/librdmacm.map
src_librspreload_la_SOURCES = src/preload.c src/indexer.c
-src_librspreload_la_LDFLAGS = -version-info 1 -export-dynamic
+src_librspreload_la_LDFLAGS = -version-info 1
+if HAVE_LD_VERSION_SCRIPT
+ src_librspreload_la_LDFLAGS += -Wl,--version-script=$(srcdir)/src/librspreload.map
+endif
src_librspreload_la_LIBADD = $(top_builddir)/src/librdmacm.la
bin_PROGRAMS = examples/ucmatose examples/rping examples/udaddy examples/mckey \
diff --git a/librdmacm/src/librspreload.map b/librdmacm/src/librspreload.map
new file mode 100644
index 000000000000..67ecf33b8203
--- /dev/null
+++ b/librdmacm/src/librspreload.map
@@ -0,0 +1,33 @@
+{
+ /* FIXME: It is probably not a great idea to not tag these with the
+ proper symbol version from glibc, at least if glibc ever changes
+ the signature this will go sideways.. */
+ global:
+ accept;
+ bind;
+ close;
+ connect;
+ dup2;
+ fcntl;
+ getpeername;
+ getsockname;
+ getsockopt;
+ listen;
+ poll;
+ read;
+ readv;
+ recv;
+ recvfrom;
+ recvmsg;
+ select;
+ send;
+ sendfile;
+ sendmsg;
+ sendto;
+ setsockopt;
+ shutdown;
+ socket;
+ write;
+ writev;
+ local: *;
+};
diff --git a/librdmacm/src/preload.c b/librdmacm/src/preload.c
index 3a0bc4c8c71d..7d9352ab1f90 100644
--- a/librdmacm/src/preload.c
+++ b/librdmacm/src/preload.c
@@ -356,7 +356,7 @@ static enum fd_type fd_close(int index, int *fd)
return type;
}
-void getenv_options(void)
+static void getenv_options(void)
{
char *var;
@@ -521,7 +521,7 @@ err:
/*
* Use defaults on failure.
*/
-void set_rsocket_options(int rsocket)
+static void set_rsocket_options(int rsocket)
{
if (sq_size)
rsetsockopt(rsocket, SOL_RDMA, RDMA_SQSIZE, &sq_size, sizeof sq_size);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 04/15] ibcm: Actually use the version script when linking
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (2 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 03/15] rdmacm: Control symbol export from librspreload Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 05/15] Include pthreads in the provider libraries Jason Gunthorpe
` (14 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
There is a typo in the Makefile.am that resulted in the version
script being ignored.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
libibcm/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libibcm/Makefile.am b/libibcm/Makefile.am
index 2333930db548..58917436d4a7 100644
--- a/libibcm/Makefile.am
+++ b/libibcm/Makefile.am
@@ -8,9 +8,9 @@ AM_CFLAGS = -g -Wall -D_GNU_SOURCE
src_libibcm_la_CFLAGS = $(AM_CFLAGS)
if HAVE_LD_VERSION_SCRIPT
- ibcm_version_script = -Wl,--version-script=$(srcdir)/src/libibcm.map
+ libibcm_version_script = -Wl,--version-script=$(srcdir)/src/libibcm.map
else
- ibcm_version_script =
+ libibcm_version_script =
endif
src_libibcm_la_SOURCES = src/cm.c
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 05/15] Include pthreads in the provider libraries
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (3 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 04/15] ibcm: Actually use the version script when linking Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 06/15] Be explicit about _GNU_SOURCE Jason Gunthorpe
` (13 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
It is a mistake to not explicitly link to the libraries required.
Not linking causes the symbols to drop the symbol version which could
cause runtime problems down the road if pthreads ever goes through
another symbol version change.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
libcxgb3/configure.in | 2 ++
libcxgb4/configure.in | 2 ++
libhfi1verbs/configure.in | 2 ++
libi40iw/configure.ac | 2 ++
libipathverbs/configure.in | 2 ++
libmlx4/configure.ac | 2 ++
libmlx5/configure.ac | 3 +++
libmthca/configure.in | 2 ++
libnes/configure.in | 2 ++
libocrdma/configure.in | 2 ++
librxe/configure.in | 2 ++
11 files changed, 23 insertions(+)
diff --git a/libcxgb3/configure.in b/libcxgb3/configure.in
index 9efc82d34f33..db9177230cae 100644
--- a/libcxgb3/configure.in
+++ b/libcxgb3/configure.in
@@ -24,6 +24,8 @@ then
AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. libcxgb3 requires libibverbs.]))
fi
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Checks for header files.
AC_CHECK_HEADERS(sysfs/libsysfs.h)
diff --git a/libcxgb4/configure.in b/libcxgb4/configure.in
index 4a74596ce8c2..336ab1c57daf 100644
--- a/libcxgb4/configure.in
+++ b/libcxgb4/configure.in
@@ -24,6 +24,8 @@ then
AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. libcxgb4 requires libibverbs.]))
fi
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Checks for header files.
AC_CHECK_HEADERS(sysfs/libsysfs.h)
diff --git a/libhfi1verbs/configure.in b/libhfi1verbs/configure.in
index 7611a55bae20..3f6e6779ce74 100644
--- a/libhfi1verbs/configure.in
+++ b/libhfi1verbs/configure.in
@@ -81,6 +81,8 @@ AC_PROG_CC
dnl Checks for libraries
AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. libhfi1verbs requires libibverbs.]))
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Checks for header files.
AC_CHECK_HEADER(infiniband/driver.h, [],
diff --git a/libi40iw/configure.ac b/libi40iw/configure.ac
index 04e246d75366..e3849b03561b 100644
--- a/libi40iw/configure.ac
+++ b/libi40iw/configure.ac
@@ -23,6 +23,8 @@ then
AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. libi40iw requires libibverbs.]))
fi
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Checks for header files.
AC_CHECK_HEADERS(sysfs/libsysfs.h)
diff --git a/libipathverbs/configure.in b/libipathverbs/configure.in
index 70093c3a8acb..f2cf2e3f90ee 100644
--- a/libipathverbs/configure.in
+++ b/libipathverbs/configure.in
@@ -81,6 +81,8 @@ AC_CHECK_SIZEOF(long)
dnl Checks for library functions
AC_CHECK_FUNCS(ibv_read_sysfs_file ibv_dontfork_range ibv_dofork_range \
ibv_register_driver)
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Now check if for libibverbs 1.0 vs 1.1
dummy=if$$
diff --git a/libmlx4/configure.ac b/libmlx4/configure.ac
index a50faa2e7353..01bf7cbcf163 100644
--- a/libmlx4/configure.ac
+++ b/libmlx4/configure.ac
@@ -29,6 +29,8 @@ AC_LANG([C])
dnl Checks for libraries
AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. libmlx4 requires libibverbs.]))
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Checks for header files.
AC_CHECK_HEADER(infiniband/driver.h, [],
diff --git a/libmlx5/configure.ac b/libmlx5/configure.ac
index c7591268a137..cd235474245e 100644
--- a/libmlx5/configure.ac
+++ b/libmlx5/configure.ac
@@ -51,6 +51,9 @@ AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_CHECK_LIB(ibverbs, ibv_register_driver_ext,
AC_DEFINE(HAVE_IBV_EXT, 1, [adding verbs extension support]))
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
+
dnl Checks for header files.
AC_CHECK_HEADER(infiniband/driver.h, [],
AC_MSG_ERROR([<infiniband/driver.h> not found. libmlx5 requires libibverbs.]))
diff --git a/libmthca/configure.in b/libmthca/configure.in
index ffd5db6962f6..fb665ed2dd40 100644
--- a/libmthca/configure.in
+++ b/libmthca/configure.in
@@ -30,6 +30,8 @@ AC_PROG_CC
dnl Checks for libraries
AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. libmthca requires libibverbs.]))
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Checks for header files.
AC_CHECK_HEADER(infiniband/driver.h, [],
diff --git a/libnes/configure.in b/libnes/configure.in
index 0cde51420753..a25d129cc159 100644
--- a/libnes/configure.in
+++ b/libnes/configure.in
@@ -23,6 +23,8 @@ then
AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. libnes requires libibverbs.]))
fi
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Checks for header files.
AC_CHECK_HEADERS(sysfs/libsysfs.h)
diff --git a/libocrdma/configure.in b/libocrdma/configure.in
index a0c8175035f9..2fd54b5ecd72 100644
--- a/libocrdma/configure.in
+++ b/libocrdma/configure.in
@@ -24,6 +24,8 @@ then
AC_CHECK_LIB(ibverbs, ibv_get_device_list, [],
AC_MSG_ERROR([ibv_get_device_list() not found. libocrdma requires libibverbs.]))
fi
+AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dnl Checks for header files.
AC_CHECK_HEADERS(sysfs/libsysfs.h)
diff --git a/librxe/configure.in b/librxe/configure.in
index 4f349cc9bae7..8927cef50468 100644
--- a/librxe/configure.in
+++ b/librxe/configure.in
@@ -36,6 +36,8 @@ if test x$enable_repackage = x || test x$enable_repackage = xno; then
AC_MSG_ERROR([<infiniband/driver.h> not found. librxe requires libibverbs.]))
AC_CHECK_FUNCS(ibv_read_sysfs_file ibv_dontfork_range ibv_dofork_range \
ibv_register_driver)
+ AC_CHECK_LIB(pthread, pthread_mutex_init, [],
+ AC_MSG_ERROR([pthread_mutex_init() not found. libibverbs requires libpthread.]))
dummy=if$$
cat <<IBV_VERSION > $dummy.c
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 06/15] Be explicit about _GNU_SOURCE
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (4 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 05/15] Include pthreads in the provider libraries Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 07/15] hfi/ipath: Use the name of the provider for the .driver file Jason Gunthorpe
` (12 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
The recommended way to use this macro is at the top of the source file,
avoid globally setting it via 'gcc -D' as few source files actually
need it. In this tree we only need it in 17 out of 83 sources.
_GNU_SOURCE changes the behaviour of a few select calls away from the C99
standard and should generally be minimized.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
libcxgb3/Makefile.am | 2 +-
libcxgb4/Makefile.am | 2 +-
libhfi1verbs/Makefile.am | 2 +-
libi40iw/Makefile.am | 2 +-
libibcm/Makefile.am | 2 +-
libibcm/src/cm.c | 2 +-
libibumad/src/sysfs.c | 3 ---
libibverbs/configure.ac | 1 -
libibverbs/examples/asyncwatch.c | 2 +-
libibverbs/examples/rc_pingpong.c | 2 +-
libibverbs/examples/srq_pingpong.c | 2 +-
libibverbs/examples/uc_pingpong.c | 2 +-
libibverbs/examples/ud_pingpong.c | 2 +-
libibverbs/examples/xsrq_pingpong.c | 2 +-
libibverbs/src/device.c | 2 +-
libibverbs/src/init.c | 2 +-
libibverbs/src/sysfs.c | 2 +-
libipathverbs/Makefile.am | 2 +-
libmlx4/Makefile.am | 2 +-
libmlx4/src/dbrec.c | 2 +-
libmlx5/Makefile.am | 2 +-
libmlx5/src/dbrec.c | 3 +--
libmlx5/src/mlx5.c | 3 +--
libmthca/Makefile.am | 2 +-
libmthca/src/memfree.c | 2 +-
libnes/Makefile.am | 2 +-
libocrdma/Makefile.am | 2 +-
librdmacm/Makefile.am | 2 +-
librdmacm/examples/rping.c | 2 +-
librdmacm/src/preload.c | 2 +-
librdmacm/src/rsocket.c | 2 +-
librxe/Makefile.am | 2 +-
32 files changed, 30 insertions(+), 36 deletions(-)
diff --git a/libcxgb3/Makefile.am b/libcxgb3/Makefile.am
index 9fa18de0c79d..99f1cae08531 100644
--- a/libcxgb3/Makefile.am
+++ b/libcxgb3/Makefile.am
@@ -2,7 +2,7 @@
lib_LTLIBRARIES = src/libcxgb3.la
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
if HAVE_LD_VERSION_SCRIPT
cxgb3_version_script = -Wl,--version-script=$(srcdir)/src/iwch.map
diff --git a/libcxgb4/Makefile.am b/libcxgb4/Makefile.am
index 97f577d55734..f75d9641ce12 100644
--- a/libcxgb4/Makefile.am
+++ b/libcxgb4/Makefile.am
@@ -1,6 +1,6 @@
lib_LTLIBRARIES = src/libcxgb4.la
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE -DNDEBUG -DOVERFLOW_DETECTION -fno-strict-aliasing
+AM_CFLAGS = -g -Wall -DNDEBUG -DOVERFLOW_DETECTION -fno-strict-aliasing
if HAVE_LD_VERSION_SCRIPT
cxgb4_version_script = -Wl,--version-script=$(srcdir)/src/cxgb4.map
diff --git a/libhfi1verbs/Makefile.am b/libhfi1verbs/Makefile.am
index d3a109203742..2c690b0570fb 100644
--- a/libhfi1verbs/Makefile.am
+++ b/libhfi1verbs/Makefile.am
@@ -51,7 +51,7 @@
# Copyright (c) 2007. QLogic Corp. All rights reserved.
# Copyright (c) 2003, 2004, 2005. PathScale, Inc. All rights reserved.
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
hfiverbs_version_script = @HFIVERBS_VERSION_SCRIPT@
diff --git a/libi40iw/Makefile.am b/libi40iw/Makefile.am
index 92772e5c8503..98d6f8ae1226 100644
--- a/libi40iw/Makefile.am
+++ b/libi40iw/Makefile.am
@@ -1,7 +1,7 @@
lib_LTLIBRARIES = src/libi40iw.la
AM_CPPFLAGS = -I$(srcdir)/src
-AM_CFLAGS = -O2 -Wall -D_GNU_SOURCE
+AM_CFLAGS = -O2 -Wall
if HAVE_LD_VERSION_SCRIPT
i40iw_version_script = -Wl,--version-script=$(srcdir)/src/i40iw.map
diff --git a/libibcm/Makefile.am b/libibcm/Makefile.am
index 58917436d4a7..ff0b1ded12a3 100644
--- a/libibcm/Makefile.am
+++ b/libibcm/Makefile.am
@@ -3,7 +3,7 @@ INCLUDES = -I$(srcdir)/include
lib_LTLIBRARIES = src/libibcm.la
ACLOCAL_AMFLAGS = -I config
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
src_libibcm_la_CFLAGS = $(AM_CFLAGS)
diff --git a/libibcm/src/cm.c b/libibcm/src/cm.c
index 996268141a04..5c56381fd5db 100644
--- a/libibcm/src/cm.c
+++ b/libibcm/src/cm.c
@@ -32,7 +32,7 @@
*
* $Id$
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibumad/src/sysfs.c b/libibumad/src/sysfs.c
index 20448d6b85bd..5d9460851897 100644
--- a/libibumad/src/sysfs.c
+++ b/libibumad/src/sysfs.c
@@ -30,9 +30,6 @@
* SOFTWARE.
*
*/
-
-#define _GNU_SOURCE
-
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/configure.ac b/libibverbs/configure.ac
index 90c33dfb7c75..a8046f3c5a72 100644
--- a/libibverbs/configure.ac
+++ b/libibverbs/configure.ac
@@ -11,7 +11,6 @@ m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
dnl Checks for programs
AC_PROG_CC
-AC_USE_SYSTEM_EXTENSIONS
AC_PROG_LN_S
LT_INIT
diff --git a/libibverbs/examples/asyncwatch.c b/libibverbs/examples/asyncwatch.c
index a77c1c8802c2..df1261503b7d 100644
--- a/libibverbs/examples/asyncwatch.c
+++ b/libibverbs/examples/asyncwatch.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/examples/rc_pingpong.c b/libibverbs/examples/rc_pingpong.c
index 8d5835774590..967678362833 100644
--- a/libibverbs/examples/rc_pingpong.c
+++ b/libibverbs/examples/rc_pingpong.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/examples/srq_pingpong.c b/libibverbs/examples/srq_pingpong.c
index f61acb006c83..a1061c31972d 100644
--- a/libibverbs/examples/srq_pingpong.c
+++ b/libibverbs/examples/srq_pingpong.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/examples/uc_pingpong.c b/libibverbs/examples/uc_pingpong.c
index 272dc2668708..b25d16c79021 100644
--- a/libibverbs/examples/uc_pingpong.c
+++ b/libibverbs/examples/uc_pingpong.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/examples/ud_pingpong.c b/libibverbs/examples/ud_pingpong.c
index 6d32cedc1284..fa99b9e51dfb 100644
--- a/libibverbs/examples/ud_pingpong.c
+++ b/libibverbs/examples/ud_pingpong.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/examples/xsrq_pingpong.c b/libibverbs/examples/xsrq_pingpong.c
index 70c576098581..ff00180f2644 100644
--- a/libibverbs/examples/xsrq_pingpong.c
+++ b/libibverbs/examples/xsrq_pingpong.c
@@ -30,7 +30,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/src/device.c b/libibverbs/src/device.c
index e520295af0c4..937e6918eb10 100644
--- a/libibverbs/src/device.c
+++ b/libibverbs/src/device.c
@@ -30,7 +30,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/src/init.c b/libibverbs/src/init.c
index dbdd7954a090..bca0e02d11e1 100644
--- a/libibverbs/src/init.c
+++ b/libibverbs/src/init.c
@@ -30,7 +30,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libibverbs/src/sysfs.c b/libibverbs/src/sysfs.c
index 0b6ad1e8cc9e..2e68da4bc97f 100644
--- a/libibverbs/src/sysfs.c
+++ b/libibverbs/src/sysfs.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libipathverbs/Makefile.am b/libipathverbs/Makefile.am
index 21cd83440b42..f9d4698c5e2c 100644
--- a/libipathverbs/Makefile.am
+++ b/libipathverbs/Makefile.am
@@ -33,7 +33,7 @@
# combinations of this program with other software, or any other
# product whatsoever.
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
ipathverbs_version_script = @IPATHVERBS_VERSION_SCRIPT@
diff --git a/libmlx4/Makefile.am b/libmlx4/Makefile.am
index d11f40ad35e3..9bb90e964fe9 100644
--- a/libmlx4/Makefile.am
+++ b/libmlx4/Makefile.am
@@ -1,4 +1,4 @@
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
mlx4_version_script = @MLX4_VERSION_SCRIPT@
diff --git a/libmlx4/src/dbrec.c b/libmlx4/src/dbrec.c
index 02ef237b3921..21ff93664df4 100644
--- a/libmlx4/src/dbrec.c
+++ b/libmlx4/src/dbrec.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libmlx5/Makefile.am b/libmlx5/Makefile.am
index 39ca65d24028..345d5afbcfee 100644
--- a/libmlx5/Makefile.am
+++ b/libmlx5/Makefile.am
@@ -1,4 +1,4 @@
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
ACLOCAL_AMFLAGS = -I m4
mlx5_version_script = @MLX5_VERSION_SCRIPT@
diff --git a/libmlx5/src/dbrec.c b/libmlx5/src/dbrec.c
index 21fcd88e323a..dbc0e650b6f4 100644
--- a/libmlx5/src/dbrec.c
+++ b/libmlx5/src/dbrec.c
@@ -29,8 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libmlx5/src/mlx5.c b/libmlx5/src/mlx5.c
index a5f8daf1fa07..790e2f0733d6 100644
--- a/libmlx5/src/mlx5.c
+++ b/libmlx5/src/mlx5.c
@@ -29,8 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libmthca/Makefile.am b/libmthca/Makefile.am
index e9be461693cd..1dd9a7ba8601 100644
--- a/libmthca/Makefile.am
+++ b/libmthca/Makefile.am
@@ -1,4 +1,4 @@
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
mthca_version_script = @MTHCA_VERSION_SCRIPT@
diff --git a/libmthca/src/memfree.c b/libmthca/src/memfree.c
index 53f01fcd6369..87de4c0f5899 100644
--- a/libmthca/src/memfree.c
+++ b/libmthca/src/memfree.c
@@ -29,7 +29,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/libnes/Makefile.am b/libnes/Makefile.am
index a5fdfc27517e..ade8e8b1eee8 100644
--- a/libnes/Makefile.am
+++ b/libnes/Makefile.am
@@ -1,7 +1,7 @@
lib_LTLIBRARIES = src/libnes.la
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
if HAVE_LD_VERSION_SCRIPT
nes_version_script = -Wl,--version-script=$(srcdir)/src/nes.map
diff --git a/libocrdma/Makefile.am b/libocrdma/Makefile.am
index c07f38c0bc65..9b786e2b51a4 100644
--- a/libocrdma/Makefile.am
+++ b/libocrdma/Makefile.am
@@ -1,7 +1,7 @@
lib_LTLIBRARIES = src/libocrdma.la
-AM_CFLAGS = -Wall -D_GNU_SOURCE
+AM_CFLAGS = -Wall
if HAVE_LD_VERSION_SCRIPT
ocrdma_version_script = -Wl,--version-script=$(srcdir)/src/ocrdma.map
diff --git a/librdmacm/Makefile.am b/librdmacm/Makefile.am
index fa82d801a4dd..edfb36bb4149 100644
--- a/librdmacm/Makefile.am
+++ b/librdmacm/Makefile.am
@@ -5,7 +5,7 @@ lib_LTLIBRARIES = src/librdmacm.la
rslib_LTLIBRARIES = src/librspreload.la
ACLOCAL_AMFLAGS = -I config
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE -DSYSCONFDIR=\"$(sysconfdir)\" -DRDMADIR=\"@rdmadir@\"
+AM_CFLAGS = -g -Wall -DSYSCONFDIR=\"$(sysconfdir)\" -DRDMADIR=\"@rdmadir@\"
src_librdmacm_la_CFLAGS = $(AM_CFLAGS)
src_librspreload_la_CFLAGS = $(AM_CFLAGS)
diff --git a/librdmacm/examples/rping.c b/librdmacm/examples/rping.c
index a5aa8c5f38d6..2f6de08dbdf9 100644
--- a/librdmacm/examples/rping.c
+++ b/librdmacm/examples/rping.c
@@ -30,7 +30,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
-
+#define _GNU_SOURCE
#include <getopt.h>
#include <stdlib.h>
#include <string.h>
diff --git a/librdmacm/src/preload.c b/librdmacm/src/preload.c
index 7d9352ab1f90..2a90f79b226c 100644
--- a/librdmacm/src/preload.c
+++ b/librdmacm/src/preload.c
@@ -30,7 +30,7 @@
* SOFTWARE.
*
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/librdmacm/src/rsocket.c b/librdmacm/src/rsocket.c
index c4f1b57dbb9a..818505fbe02e 100644
--- a/librdmacm/src/rsocket.c
+++ b/librdmacm/src/rsocket.c
@@ -30,7 +30,7 @@
* SOFTWARE.
*
*/
-
+#define _GNU_SOURCE
#if HAVE_CONFIG_H
# include <config.h>
#endif /* HAVE_CONFIG_H */
diff --git a/librxe/Makefile.am b/librxe/Makefile.am
index fe6c36c4eaba..972ae3b390b7 100644
--- a/librxe/Makefile.am
+++ b/librxe/Makefile.am
@@ -1,4 +1,4 @@
-AM_CFLAGS = -g -Wall -D_GNU_SOURCE
+AM_CFLAGS = -g -Wall
rxe_version_script = @RXE_VERSION_SCRIPT@
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 07/15] hfi/ipath: Use the name of the provider for the .driver file
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (5 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 06/15] Be explicit about _GNU_SOURCE Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 08/15] Unified CMake build system Jason Gunthorpe
` (11 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
The standard is to use the same name for the library and .driver
file. The library is called hfi1verbs/ipathverbs so should the .driver,
add the verbs suffix.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
libhfi1verbs/Makefile.am | 4 ++--
libhfi1verbs/{hfi1.driver => hfi1verbs.driver} | 0
libipathverbs/Makefile.am | 4 ++--
libipathverbs/{ipath.driver => ipathverbs.driver} | 0
4 files changed, 4 insertions(+), 4 deletions(-)
rename libhfi1verbs/{hfi1.driver => hfi1verbs.driver} (100%)
rename libipathverbs/{ipath.driver => ipathverbs.driver} (100%)
diff --git a/libhfi1verbs/Makefile.am b/libhfi1verbs/Makefile.am
index 2c690b0570fb..d86ea3dd57e6 100644
--- a/libhfi1verbs/Makefile.am
+++ b/libhfi1verbs/Makefile.am
@@ -63,7 +63,7 @@ if HAVE_IBV_DEVICE_LIBRARY_EXTENSION
src_libhfi1verbs_la_LDFLAGS = -avoid-version -release @IBV_DEVICE_LIBRARY_EXTENSION@ \
$(hfiverbs_version_script)
hfiverbsconfdir = $(sysconfdir)/libibverbs.d
- hfiverbsconf_DATA = hfi1.driver
+ hfiverbsconf_DATA = hfi1verbs.driver
else
hfiverbslibdir = $(libdir)/infiniband
hfiverbslib_LTLIBRARIES = src/hfiverbs.la
@@ -77,7 +77,7 @@ EXTRA_DIST = src/hfiverbs.h \
config \
autom4te.cache \
libhfi1verbs.spec.in \
- hfi1.driver
+ hfi1verbs.driver
dist-hook: libhfi1verbs.spec
cp libhfi1verbs.spec $(distdir)
diff --git a/libhfi1verbs/hfi1.driver b/libhfi1verbs/hfi1verbs.driver
similarity index 100%
rename from libhfi1verbs/hfi1.driver
rename to libhfi1verbs/hfi1verbs.driver
diff --git a/libipathverbs/Makefile.am b/libipathverbs/Makefile.am
index f9d4698c5e2c..4d3e9258d989 100644
--- a/libipathverbs/Makefile.am
+++ b/libipathverbs/Makefile.am
@@ -45,7 +45,7 @@ if HAVE_IBV_DEVICE_LIBRARY_EXTENSION
src_libipathverbs_la_LDFLAGS = -avoid-version -release @IBV_DEVICE_LIBRARY_EXTENSION@ \
$(ipathverbs_version_script)
ipathverbsconfdir = $(sysconfdir)/libibverbs.d
- ipathverbsconf_DATA = ipath.driver
+ ipathverbsconf_DATA = ipathverbs.driver
else
ipathverbslibdir = $(libdir)/infiniband
ipathverbslib_LTLIBRARIES = src/ipathverbs.la
@@ -59,7 +59,7 @@ EXTRA_DIST = src/ipathverbs.h \
src/ipath-abi.h \
src/ipathverbs.map \
libipathverbs.spec.in \
- ipath.driver \
+ ipathverbs.driver \
truescale-serdes.cmds \
truescale.conf
diff --git a/libipathverbs/ipath.driver b/libipathverbs/ipathverbs.driver
similarity index 100%
rename from libipathverbs/ipath.driver
rename to libipathverbs/ipathverbs.driver
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 08/15] Unified CMake build system
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (6 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 07/15] hfi/ipath: Use the name of the provider for the .driver file Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 09/15] Support obsolete cmake from 2013 Jason Gunthorpe
` (10 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
This replaces the random selection of auto* and custom stuff with a
simple unified cmake based scheme.
The input from cpp to gcc is validated to be identical.
An analysis of the post-install result shows the following differences:
- cmake makes shlib symlinks libX.so -> libX.so.1 -> libX.so.1.0.0, while
libtool does libX.so -> libX.so.1.0.0
- librspreload's non-link name is lib/rsocket/librspreload.so (not .so.1)
This correctly reflects the fact it is a soname-less LD_PRELOAD library.
Symlinks are maintained for the other two incorrect names.
- No static version of librspreload is produced. This library is only
useful for LD_PRELOAD and cannot be statically linked to.
- The provider shared library plugins and the LD_PRELOAD library
have no SONAME. This is standard for plugin libraries.
- The plugin shared libraries are not marked executable
- -std=gnu99 is turned on globally
- All shlibs have correct shared library dependencies (--as-needed and
--no-undefined are turned on).
Several binaries drop their pthreads dependency as they don't use it.
- NDEBUG is controlled globally and is not defined.
Previously only libcxgb4 defined it
- libtool *.la files are produced by cmake since libtool is not used
and have a few minor differences:
- Providers do not list the 'libX.so' bogus name, the .so is called
libX-rdmav2.so
- version information (current/age/revision) is bogus
- The .la files are not marked executable
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
CMakeLists.txt | 232 ++++++++++++++++++++++++++
README.md | 69 ++++++++
buildlib/FindLDSymVer.cmake | 41 +++++
buildlib/RDMA_BuildType.cmake | 31 ++++
buildlib/RDMA_DoFixup.cmake | 21 +++
buildlib/RDMA_EnableCStd.cmake | 23 +++
buildlib/config.h.in | 29 ++++
buildlib/fixup-include/rdma-rdma_user_rxe.h | 144 +++++++++++++++++
buildlib/fixup-include/valgrind-memcheck.h | 5 +
buildlib/provider.map | 6 +
| 20 +++
buildlib/rdma_functions.cmake | 242 ++++++++++++++++++++++++++++
libcxgb3/src/CMakeLists.txt | 6 +
libcxgb4/src/CMakeLists.txt | 6 +
libhfi1verbs/src/CMakeLists.txt | 4 +
libi40iw/src/CMakeLists.txt | 5 +
libibcm/examples/CMakeLists.txt | 2 +
libibcm/src/CMakeLists.txt | 9 ++
libibumad/man/CMakeLists.txt | 42 +++++
libibumad/src/CMakeLists.txt | 14 ++
libibumad/tests/CMakeLists.txt | 5 +
libibverbs/examples/CMakeLists.txt | 29 ++++
libibverbs/man/CMakeLists.txt | 78 +++++++++
libibverbs/src/CMakeLists.txt | 34 ++++
libipathverbs/CMakeLists.txt | 4 +
libipathverbs/src/CMakeLists.txt | 4 +
libmlx4/src/CMakeLists.txt | 9 ++
libmlx5/src/CMakeLists.txt | 9 ++
libmthca/src/CMakeLists.txt | 10 ++
libnes/src/CMakeLists.txt | 4 +
libocrdma/src/CMakeLists.txt | 4 +
librdmacm/examples/CMakeLists.txt | 43 +++++
librdmacm/man/CMakeLists.txt | 65 ++++++++
librdmacm/src/CMakeLists.txt | 39 +++++
librxe/CMakeLists.txt | 4 +
librxe/man/CMakeLists.txt | 4 +
librxe/src/CMakeLists.txt | 3 +
37 files changed, 1299 insertions(+)
create mode 100644 CMakeLists.txt
create mode 100644 README.md
create mode 100644 buildlib/FindLDSymVer.cmake
create mode 100644 buildlib/RDMA_BuildType.cmake
create mode 100644 buildlib/RDMA_DoFixup.cmake
create mode 100644 buildlib/RDMA_EnableCStd.cmake
create mode 100644 buildlib/config.h.in
create mode 100644 buildlib/fixup-include/rdma-rdma_user_rxe.h
create mode 100644 buildlib/fixup-include/valgrind-memcheck.h
create mode 100644 buildlib/provider.map
create mode 100644 buildlib/publish_headers.cmake
create mode 100644 buildlib/rdma_functions.cmake
create mode 100644 libcxgb3/src/CMakeLists.txt
create mode 100644 libcxgb4/src/CMakeLists.txt
create mode 100644 libhfi1verbs/src/CMakeLists.txt
create mode 100644 libi40iw/src/CMakeLists.txt
create mode 100644 libibcm/examples/CMakeLists.txt
create mode 100644 libibcm/src/CMakeLists.txt
create mode 100644 libibumad/man/CMakeLists.txt
create mode 100644 libibumad/src/CMakeLists.txt
create mode 100644 libibumad/tests/CMakeLists.txt
create mode 100644 libibverbs/examples/CMakeLists.txt
create mode 100644 libibverbs/man/CMakeLists.txt
create mode 100644 libibverbs/src/CMakeLists.txt
create mode 100644 libipathverbs/CMakeLists.txt
create mode 100644 libipathverbs/src/CMakeLists.txt
create mode 100644 libmlx4/src/CMakeLists.txt
create mode 100644 libmlx5/src/CMakeLists.txt
create mode 100644 libmthca/src/CMakeLists.txt
create mode 100644 libnes/src/CMakeLists.txt
create mode 100644 libocrdma/src/CMakeLists.txt
create mode 100644 librdmacm/examples/CMakeLists.txt
create mode 100644 librdmacm/man/CMakeLists.txt
create mode 100644 librdmacm/src/CMakeLists.txt
create mode 100644 librxe/CMakeLists.txt
create mode 100644 librxe/man/CMakeLists.txt
create mode 100644 librxe/src/CMakeLists.txt
diff --git a/CMakeLists.txt b/CMakeLists.txt
new file mode 100644
index 000000000000..568e819aa976
--- /dev/null
+++ b/CMakeLists.txt
@@ -0,0 +1,232 @@
+# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
+# Run cmake as:
+# mkdir build
+# cmake -GNinja ..
+# ninja
+#
+# Common options passed to cmake are:
+# -DCMAKE_EXPORT_COMPILE_COMMANDS=1
+# Write a compile_commands.json file for clang tooling
+# -DCMAKE_BUILD_TYPE=RelWithDebInfo
+# Change the optimization level, Debug disables optimization
+# -DENABLE_VALGRIND=1 (default disabled)
+# Embed valgrind notations, this has a tiny negative performance impact
+# -DENABLE_RESOLVE_NEIGH=0 (default enabled)
+# Do not link to libnl and do not resolve neighbours internally for Ethernet.
+
+cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR)
+project(RDMA C)
+
+set(PACKAGE_NAME "RDMA")
+# FIXME versioning strategy?
+set(PACKAGE_VERSION "1")
+
+#-------------------------
+# Basic standard paths
+# C include root
+set(BUILD_INCLUDE ${CMAKE_BINARY_DIR}/include)
+# Executables
+set(BUILD_BIN ${CMAKE_BINARY_DIR}/bin)
+# Libraries
+set(BUILD_LIB ${CMAKE_BINARY_DIR}/lib)
+
+set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/etc")
+# Location to place provider .driver files
+set(CONFIG_DIR "${SYSCONFDIR}/libibverbs.d")
+
+#-------------------------
+# Load CMake components
+set(BUILDLIB "${CMAKE_SOURCE_DIR}/buildlib")
+set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${BUILDLIB}")
+
+include(FindPkgConfig)
+include(CheckCCompilerFlag)
+include(CheckIncludeFile)
+include(RDMA_EnableCStd)
+include(RDMA_BuildType)
+include(RDMA_DoFixup)
+include(publish_headers)
+include(rdma_functions)
+
+#-------------------------
+# Setup the basic C compiler
+RDMA_BuildType()
+include_directories(${BUILD_INCLUDE})
+# FIXME: Eliminate HAVE_CONFIG_H, we always have it.
+add_definitions(-DHAVE_CONFIG_H)
+add_definitions(-DIBV_CONFIG_DIR="${CONFIG_DIR}")
+
+# Require GNU99 mode
+RDMA_EnableCStd()
+
+# The code does not do the racy fcntl if the various CLOEXEC's are not
+# supported so it really doesn't work right if this isn't available. Thus hard
+# require it.
+CHECK_C_SOURCE_COMPILES("
+ #include <sys/types.h>
+ #include <sys/stat.h>
+ #include <sys/socket.h>
+ #include <fcntl.h>
+ int main(int argc,const char *argv[]) {
+ open(\".\",O_RDONLY | O_CLOEXEC);
+ socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0);
+ return 0;
+ }" HAS_CLOEXEC)
+if (NOT HAS_CLOEXEC)
+ message(FATAL_ERROR "O_CLOEXEC/SOCK_CLOEXEC/fopen(..,\"e\") support is required but not found")
+endif()
+
+# always_inline is supported
+CHECK_C_SOURCE_COMPILES("
+ inline __attribute__((always_inline)) int foo(void) {return 0;}
+ int main(int argc,const char *argv[]) { return foo(); }"
+ HAVE_FUNC_ATTRIBUTE_ALWAYS_INLINE
+ FAIL_REGEX "warning")
+
+# Enable development support features
+# Prune unneeded shared libraries during linking
+RDMA_AddOptCFlag(CMAKE_EXE_LINKER_FLAGS SUPPORTS_AS_NEEDED "-Wl,--as-needed")
+RDMA_AddOptCFlag(CMAKE_SHARED_LINKER_FLAGS SUPPORTS_AS_NEEDED "-Wl,--as-needed")
+
+# Ensure all shared ELFs have fully described linking
+RDMA_AddOptCFlag(CMAKE_EXEC_LINKER_FLAGS SUPPORTS_NO_UNDEFINED "-Wl,--no-undefined")
+RDMA_AddOptCFlag(CMAKE_SHARED_LINKER_FLAGS SUPPORTS_NO_UNDEFINED "-Wl,--no-undefined")
+
+# Enable gold linker - gold has different linking checks
+#RDMA_AddOptCFlag(CMAKE_EXEC_LINKER_FLAGS SUPPORTS_NO_UNDEFINED "-fuse-ld=gold")
+#RDMA_AddOptCFlag(CMAKE_SHARED_LINKER_FLAGS SUPPORTS_NO_UNDEFINED "-fuse-ld=gold")
+
+# Verify that GNU --version-script and asm(".symver") works
+find_package(LDSymVer REQUIRED)
+
+#-------------------------
+# Find libraries
+# pthread
+FIND_PACKAGE (Threads REQUIRED)
+
+# libnl
+if ((NOT DEFINED ENABLE_RESOLVE_NEIGH) OR (ENABLE_RESOLVE_NEIGH))
+ # FIXME use of pkgconfig is discouraged
+ pkg_check_modules(NL3 libnl-3.0 libnl-route-3.0)
+ if (NOT NL3_FOUND)
+ # FIXME: I don't know why we have this fallback, all supported distros
+ # have libnl3
+ pkg_check_modules(NL1 libnl-1)
+ if (NOT NL1_FOUND)
+ message(FATAL_ERROR "Cannot find libnl-3.0 or libnl-1")
+ endif()
+ set(NL_KIND 1)
+ set(NL_INCLUDE_DIRS ${NL1_INCLUDE_DIRS})
+ set(NL_LIBRARIES ${NL1_LIBRARIES})
+ else()
+ set(NL_KIND 3)
+ set(NL_INCLUDE_DIRS ${NL3_INCLUDE_DIRS})
+ set(NL_LIBRARIES ${NL3_LIBRARIES})
+ endif()
+
+ include_directories(${NL_INCLUDE_DIRS})
+else()
+ set(NL_KIND 0)
+ set(NL_LIBRARIES "")
+endif()
+
+# Statically determine sizeof(long), this is largely unnecessary, no new code
+# should rely on this.
+CHECK_C_SOURCE_COMPILES("
+ char dummy[sizeof(long) == 8?1:-1];
+ int main(int argc,const char *argv[]) { return 0; }"
+ SIZEOF_LONG_8)
+if (NOT SIZEOF_LONG_8)
+ CHECK_C_SOURCE_COMPILES("
+ char dummy[sizeof(long) == 4?1:-1];
+ int main(int argc,const char *argv[]) { return 0; }"
+ SIZEOF_LONG_4)
+endif()
+if (SIZEOF_LONG_8)
+ set(SIZEOF_LONG 8)
+elseif(SIZEOF_LONG_4)
+ set(SIZEOF_LONG 4)
+else()
+ message(FATAL_ERROR "Could not determine sizeof(long)")
+endif()
+
+# Are our kernel headers new enough?
+# If not replace them with built-in copies so we can continue to build.
+CHECK_INCLUDE_FILE("rdma/rdma_user_rxe.h" HAVE_RDMA_USER_RXE)
+RDMA_DoFixup("${HAVE_RDMA_USER_RXE}" "rdma/rdma_user_rxe.h")
+
+#-------------------------
+# Apply fixups
+
+# FIXME: We should probably always enable memcheck.h, and only selectively
+# turn it off in the real high performance paths. There is no reason umad
+# should ever have memcheck disabled for instance.
+if (ENABLE_VALGRIND)
+ CHECK_INCLUDE_FILE("valgrind/memcheck.h" ENABLE_VALGRIND)
+endif()
+RDMA_DoFixup("${ENABLE_VALGRIND}" "valgrind/memcheck.h")
+
+#-------------------------
+# Build Prep
+# Write out a git ignore file to the build directory if it isn't the source
+# directory. For developer convenience
+if (NOT ${CMAKE_CURRENT_BINARY_DIR} STREQUAL ${CMAKE_CURRENT_SOURCE_DIR})
+ file(WRITE ${CMAKE_BINARY_DIR}/.gitignore "*")
+endif()
+
+configure_file(${BUILDLIB}/config.h.in ${BUILD_INCLUDE}/config.h)
+
+#-------------------------
+# Sub-directories
+# Libraries
+add_subdirectory(libibumad/src)
+add_subdirectory(libibumad/man)
+add_subdirectory(libibverbs/src)
+add_subdirectory(libibverbs/man)
+add_subdirectory(librdmacm/src)
+add_subdirectory(librdmacm/man)
+add_subdirectory(libibcm/src)
+
+# Providers
+add_subdirectory(libcxgb3/src)
+add_subdirectory(libcxgb4/src)
+add_subdirectory(libhfi1verbs/src)
+add_subdirectory(libi40iw/src)
+add_subdirectory(libipathverbs/src)
+add_subdirectory(libipathverbs/)
+add_subdirectory(libmlx4/src)
+add_subdirectory(libmlx5/src)
+add_subdirectory(libmthca/src)
+add_subdirectory(libnes/src)
+add_subdirectory(libocrdma/src)
+add_subdirectory(librxe/src)
+add_subdirectory(librxe/man)
+add_subdirectory(librxe/)
+
+# Binaries
+add_subdirectory(libibcm/examples)
+add_subdirectory(libibumad/tests)
+add_subdirectory(libibverbs/examples)
+add_subdirectory(librdmacm/examples)
+
+rdma_finalize_libs()
+
+#-------------------------
+# Display a summary
+# Only report things that are non-ideal
+message(STATUS "Missing Optional Items:")
+if (NOT HAVE_FUNC_ATTRIBUTE_ALWAYS_INLINE)
+ message(STATUS " Compiler attribute always_inline NOT supported")
+endif()
+if (NOT ENABLE_VALGRIND)
+ message(STATUS " Valgrind memcheck.h NOT enabled")
+endif()
+if (NL_KIND EQUAL 1)
+ message(STATUS " libnl 3 NOT found (using libnl 1 compat)")
+endif()
+if (NL_KIND EQUAL 0)
+ message(STATUS " neighbour resolution NOT enabled")
+endif()
+if (NOT HAVE_RDMA_USER_RXE)
+ message(STATUS " rdma/rdma_user_rxe.h NOT found (old system kernel headers)")
+endif()
diff --git a/README.md b/README.md
new file mode 100644
index 000000000000..b3e9b20f7987
--- /dev/null
+++ b/README.md
@@ -0,0 +1,69 @@
+# RDMA Plumbing
+
+This is the userspace components for the Linux Kernel's drivers/infiniband
+subsystem. Specifically this contains the userspace libraries for the
+following device nodes:
+
+ - /dev/infiniband/uverbsX (libibverbs)
+ - /dev/infiniband/rdma_cm (librdmacm)
+ - /dev/infiniband/umadX (libumad)
+ - /dev/infiniband/ucmX (libibcm, deprecated)
+
+Further, the userspace component of the RDMA kernel drivers are included under
+the providers/ directory. Support for the following Kernel RDMA drivers is
+included:
+
+ - iw_cxgb3.ko
+ - iw_cxgb4.ko
+ - hfi1.ko
+ - i40iw.ko
+ - ib_qib.ko
+ - mlx4_ib.ko
+ - mlx5_ib.ko
+ - ib_mthca.ko
+ - iw_nes.ko
+ - ocrdma.ko
+ - rdma_rxe.ko
+
+# Building
+
+This project uses a cmake based build system. Quick start:
+
+```sh
+$ mkdir build
+$ cd build
+$ cmake -GNinja ..
+$ ninja
+```
+
+*build/bin* will contain the sample programs and *build/lib* will contain the
+shared libraries.
+
+NOTE: Fedora Core uses the name 'ninja-build' for the ninja command.
+
+NOTE: It is not currently easy to run from the build directory, the plugins
+only load from the system path.
+
+# Building on CentOS 6/7
+
+For end users, the package can be built using GNU Make and the old cmake
+included with the distro:
+
+```sh
+$ mkdir build
+$ cd build
+$ cmake ..
+$ make
+```
+
+Developers are suggested to install more modern tooling for the best experience.
+
+```sh
+$ yum install epel-release
+$ yum install cmake3 unzip
+$ curl -OL https://github.com/ninja-build/ninja/releases/download/v1.7.1/ninja-linux.zip
+$ unzip ninja-linux.zip
+$ install -m755 ninja /usr/local/bin/ninja
+```
+
+Use the 'cmake3' program in place of `cmake` in the above instructions.
\ No newline at end of file
diff --git a/buildlib/FindLDSymVer.cmake b/buildlib/FindLDSymVer.cmake
new file mode 100644
index 000000000000..df86bb3aa31a
--- /dev/null
+++ b/buildlib/FindLDSymVer.cmake
@@ -0,0 +1,41 @@
+# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
+# find_package helper to detect symbol version support in the compiler and
+# linker. If supported then LDSYMVER_MODE will be set to GNU
+
+# Basic sample GNU style map file
+file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/test.map" "
+IBVERBS_1.0 {
+ global:
+ ibv_get_device_list;
+ local: *;
+};
+
+IBVERBS_1.1 {
+ global:
+ ibv_get_device_list;
+} IBVERBS_1.0;
+")
+
+set(CMAKE_REQUIRED_FLAGS_SAVE ${CMAKE_REQUIRED_FLAGS})
+set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS} "-Wl,--version-script=${CMAKE_CURRENT_BINARY_DIR}/test.map")
+
+# And matching source, this also checks that .symver asm works
+check_c_source_compiles("
+void ibv_get_device_list_1(void){}
+asm(\".symver ibv_get_device_list_1, ibv_get_device_list @ IBVERBS_1.1\");
+void ibv_get_device_list_0(void){}
+asm(\".symver ibv_get_device_list_0, ibv_get_device_list @@ IBVERBS_1.0\");
+
+int main(void){return 0;}" _LDSYMVER_SUCCESS)
+file(REMOVE "${CMAKE_CURRENT_BINARY_DIR}/test.map")
+set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS_SAVE})
+
+if (_LDSYMVER_SUCCESS)
+ set(LDSYMVER_MODE "GNU" CACHE STRING "How to set symbol versions on shared libraries")
+endif()
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(
+ LDSymVer
+ REQUIRED_VARS LDSYMVER_MODE
+ )
diff --git a/buildlib/RDMA_BuildType.cmake b/buildlib/RDMA_BuildType.cmake
new file mode 100644
index 000000000000..f5dab4397709
--- /dev/null
+++ b/buildlib/RDMA_BuildType.cmake
@@ -0,0 +1,31 @@
+# COPYRIGHT (c) 2015 Obsidian Research Corporation. See COPYING file
+
+# Set the default build type to RelWithDebInfo. Since RDMA is typically used
+# in performance contexts it doesn't make much sense to have the default build
+# turn off the optimizer.
+function(RDMA_BuildType)
+ set(build_types Debug Release RelWithDebInfo MinSizeRel)
+
+ if(NOT CMAKE_BUILD_TYPE)
+ set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE String
+ "Options are ${build_types}"
+ FORCE
+ )
+ set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS ${build_types})
+ endif()
+
+ # Remove NDEBUG from all the default cmake configs, this disables assert,
+ # which we don't want to ever do.
+ foreach (build_config ${build_types})
+ string(TOUPPER ${build_config} upper_case_build_config)
+ foreach (language CXX C)
+ set(VAR_TO_MODIFY "CMAKE_${language}_FLAGS_${upper_case_build_config}")
+ string(REGEX REPLACE "(^| )[/-]D *NDEBUG($| )"
+ " "
+ replacement
+ "${${VAR_TO_MODIFY}}"
+ )
+ set(${VAR_TO_MODIFY} "${replacement}" CACHE STRING "Default flags for ${build_config} configuration" FORCE)
+ endforeach()
+ endforeach()
+endfunction()
diff --git a/buildlib/RDMA_DoFixup.cmake b/buildlib/RDMA_DoFixup.cmake
new file mode 100644
index 000000000000..1e30cf6c761b
--- /dev/null
+++ b/buildlib/RDMA_DoFixup.cmake
@@ -0,0 +1,21 @@
+# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
+
+# Execute a header fixup based on NOT_NEEDED for HEADER
+
+# The buildlib includes alternate header file shims for several scenarios, if
+# the build system detects a feature is present then it should call OrcDoFixup
+# with the test as true. If false then the shim header will be installed.
+
+# Typically the shim header will replace a missing header with stubs, or it
+# will augment an existing header with include_next.
+function(RDMA_DoFixup not_needed header)
+ set(DEST "${BUILD_INCLUDE}/${header}")
+ if (NOT "${not_needed}")
+ get_filename_component(DIR ${DEST} DIRECTORY)
+ file(MAKE_DIRECTORY "${DIR}")
+ string(REPLACE / - header-bl ${header})
+ execute_process(COMMAND "ln" "-Tsf" "${BUILDLIB}/fixup-include/${header-bl}" "${DEST}")
+ else()
+ file(REMOVE ${DEST})
+ endif()
+endfunction()
diff --git a/buildlib/RDMA_EnableCStd.cmake b/buildlib/RDMA_EnableCStd.cmake
new file mode 100644
index 000000000000..9cbbb881cd19
--- /dev/null
+++ b/buildlib/RDMA_EnableCStd.cmake
@@ -0,0 +1,23 @@
+# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
+
+# Test if the CC compiler supports the flag and if so add it to TO_VAR
+function(RDMA_AddOptCFlag TO_VAR CACHE_VAR FLAG)
+ CHECK_C_COMPILER_FLAG("${FLAG}" ${CACHE_VAR})
+ if (${CACHE_VAR})
+ SET(${TO_VAR} "${${TO_VAR}} ${FLAG}" PARENT_SCOPE)
+ endif()
+endfunction()
+
+# Enable the minimum required gnu99 standard in the compiler.
+function(RDMA_EnableCStd)
+ if (CMAKE_VERSION VERSION_LESS "3.1")
+ # Check for support of the usual flag
+ CHECK_C_COMPILER_FLAG("-std=gnu99" SUPPORTS_GNU99)
+ if (SUPPORTS_GNU99)
+ SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99" PARENT_SCOPE)
+ endif()
+ else()
+ # Newer cmake can do this internally
+ set(CMAKE_C_STANDARD 99 PARENT_SCOPE)
+ endif()
+endfunction()
diff --git a/buildlib/config.h.in b/buildlib/config.h.in
new file mode 100644
index 000000000000..1e487fc6aa6b
--- /dev/null
+++ b/buildlib/config.h.in
@@ -0,0 +1,29 @@
+// FIXME: Remove this, ibverbs is included so we don't need to detect
+#define HAVE_IBV_DOFORK_RANGE 1
+#define HAVE_IBV_DONTFORK_RANGE 1
+#define HAVE_IBV_REGISTER_DRIVER 1
+#define HAVE_IBV_READ_SYSFS_FILE 1
+
+// FIXME: Remove this, The cmake version hard-requires symbol version support
+#define HAVE_SYMVER_SUPPORT 1
+
+// FIXME: Remove this, The cmake version hard-requires new style CLOEXEC support
+#define STREAM_CLOEXEC "e"
+
+// FIXME: Remove this, cmake always provides a valgrind/memcheck.h
+#define HAVE_VALGRIND_MEMCHECK_H 1
+
+#define SYSCONFDIR "@SYSCONFDIR@"
+
+// FIXME This has been supported in compilers forever, we should just fail to build on such old systems.
+#cmakedefine HAVE_FUNC_ATTRIBUTE_ALWAYS_INLINE 1
+
+#cmakedefine SIZEOF_LONG @SIZEOF_LONG@
+
+#if @NL_KIND@ == 3
+# define HAVE_LIBNL3 1
+#elif @NL_KIND@ == 1
+# define HAVE_LIBNL1 1
+#elif @NL_KIND@ == 0
+# define NRESOLVE_NEIGH 1
+#endif
diff --git a/buildlib/fixup-include/rdma-rdma_user_rxe.h b/buildlib/fixup-include/rdma-rdma_user_rxe.h
new file mode 100644
index 000000000000..1de99cfdaf7d
--- /dev/null
+++ b/buildlib/fixup-include/rdma-rdma_user_rxe.h
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) 2016 Mellanox Technologies Ltd. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef RDMA_USER_RXE_H
+#define RDMA_USER_RXE_H
+
+#include <linux/types.h>
+
+union rxe_gid {
+ __u8 raw[16];
+ struct {
+ __be64 subnet_prefix;
+ __be64 interface_id;
+ } global;
+};
+
+struct rxe_global_route {
+ union rxe_gid dgid;
+ __u32 flow_label;
+ __u8 sgid_index;
+ __u8 hop_limit;
+ __u8 traffic_class;
+};
+
+struct rxe_av {
+ __u8 port_num;
+ __u8 network_type;
+ struct rxe_global_route grh;
+ union {
+ struct sockaddr _sockaddr;
+ struct sockaddr_in _sockaddr_in;
+ struct sockaddr_in6 _sockaddr_in6;
+ } sgid_addr, dgid_addr;
+};
+
+struct rxe_send_wr {
+ __u64 wr_id;
+ __u32 num_sge;
+ __u32 opcode;
+ __u32 send_flags;
+ union {
+ __be32 imm_data;
+ __u32 invalidate_rkey;
+ } ex;
+ union {
+ struct {
+ __u64 remote_addr;
+ __u32 rkey;
+ } rdma;
+ struct {
+ __u64 remote_addr;
+ __u64 compare_add;
+ __u64 swap;
+ __u32 rkey;
+ } atomic;
+ struct {
+ __u32 remote_qpn;
+ __u32 remote_qkey;
+ __u16 pkey_index;
+ } ud;
+ struct {
+ struct ib_mr *mr;
+ __u32 key;
+ int access;
+ } reg;
+ } wr;
+};
+
+struct rxe_sge {
+ __u64 addr;
+ __u32 length;
+ __u32 lkey;
+};
+
+struct mminfo {
+ __u64 offset;
+ __u32 size;
+ __u32 pad;
+};
+
+struct rxe_dma_info {
+ __u32 length;
+ __u32 resid;
+ __u32 cur_sge;
+ __u32 num_sge;
+ __u32 sge_offset;
+ union {
+ __u8 inline_data[0];
+ struct rxe_sge sge[0];
+ };
+};
+
+struct rxe_send_wqe {
+ struct rxe_send_wr wr;
+ struct rxe_av av;
+ __u32 status;
+ __u32 state;
+ __u64 iova;
+ __u32 mask;
+ __u32 first_psn;
+ __u32 last_psn;
+ __u32 ack_length;
+ __u32 ssn;
+ __u32 has_rd_atomic;
+ struct rxe_dma_info dma;
+};
+
+struct rxe_recv_wqe {
+ __u64 wr_id;
+ __u32 num_sge;
+ __u32 padding;
+ struct rxe_dma_info dma;
+};
+
+#endif /* RDMA_USER_RXE_H */
diff --git a/buildlib/fixup-include/valgrind-memcheck.h b/buildlib/fixup-include/valgrind-memcheck.h
new file mode 100644
index 000000000000..6457a5a0f6a1
--- /dev/null
+++ b/buildlib/fixup-include/valgrind-memcheck.h
@@ -0,0 +1,5 @@
+static inline void VALGRIND_MAKE_MEM_DEFINED(const void *mem,size_t len) {}
+#define VALGRIND_MAKE_MEM_DEFINED VALGRIND_MAKE_MEM_DEFINED
+
+static inline void VALGRIND_MAKE_MEM_UNDEFINED(const void *mem,size_t len) {}
+#define VALGRIND_MAKE_MEM_UNDEFINED VALGRIND_MAKE_MEM_UNDEFINED
diff --git a/buildlib/provider.map b/buildlib/provider.map
new file mode 100644
index 000000000000..4ede3a8b1dc0
--- /dev/null
+++ b/buildlib/provider.map
@@ -0,0 +1,6 @@
+/* The providers do not export any symbols at all. Instead they rely on
+ attribute(constructor) to cause their init function to run at dlopen
+ time. */
+{
+ local: *;
+};
\ No newline at end of file
--git a/buildlib/publish_headers.cmake b/buildlib/publish_headers.cmake
new file mode 100644
index 000000000000..91fc386d0e64
--- /dev/null
+++ b/buildlib/publish_headers.cmake
@@ -0,0 +1,20 @@
+# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
+
+# Copy headers from the source directory to the proper place in the
+# build/include directory
+function(PUBLISH_HEADERS DEST)
+ if(NOT ARGN)
+ message(SEND_ERROR "Error: PUBLISH_HEADERS called without any files")
+ return()
+ endif()
+
+ set(DDIR "${BUILD_INCLUDE}/${DEST}")
+ file(MAKE_DIRECTORY "${DDIR}")
+
+ foreach(SFIL ${ARGN})
+ get_filename_component(FIL ${SFIL} NAME)
+ execute_process(COMMAND "ln" "-Tsf"
+ "${CMAKE_CURRENT_SOURCE_DIR}/${SFIL}" "${DDIR}/${FIL}")
+ install(FILES "${SFIL}" DESTINATION "include/${DEST}/" RENAME "${FIL}")
+ endforeach()
+endfunction()
diff --git a/buildlib/rdma_functions.cmake b/buildlib/rdma_functions.cmake
new file mode 100644
index 000000000000..f698855563e9
--- /dev/null
+++ b/buildlib/rdma_functions.cmake
@@ -0,0 +1,242 @@
+# COPYRIGHT (c) 2016 Obsidian Research Corporation. See COPYING file
+
+# Helper functions for use in the sub CMakeLists files to make them simpler
+# and more uniform.
+
+# Global list of pairs of (SHARED STATIC) libary target names
+set(RDMA_STATIC_LIBS "" CACHE INTERNAL "Doc" FORCE)
+
+# Modify shared library target DEST to use VERSION_SCRIPT as the linker map file
+function(rdma_set_library_map DEST VERSION_SCRIPT)
+ if (NOT IS_ABSOLUTE ${VERSION_SCRIPT})
+ set(VERSION_SCRIPT "${CMAKE_CURRENT_SOURCE_DIR}/${VERSION_SCRIPT}")
+ endif()
+ set_property(TARGET ${DEST} APPEND_STRING PROPERTY
+ LINK_FLAGS " -Wl,--version-script,${VERSION_SCRIPT}")
+
+ # NOTE: This won't work with ninja prior to cmake 3.4
+ set_property(TARGET ${DEST} APPEND_STRING PROPERTY
+ LINK_DEPENDS ${VERSION_SCRIPT})
+endfunction()
+
+# Basic function to produce a standard libary with a GNU LD version script.
+function(rdma_library DEST VERSION_SCRIPT SOVERSION VERSION)
+ # Create a static library
+ add_library(${DEST}-static STATIC ${ARGN})
+ set_target_properties(${DEST}-static PROPERTIES
+ OUTPUT_NAME ${DEST}
+ LIBRARY_OUTPUT_DIRECTORY "${BUILD_LIB}")
+ install(TARGETS ${DEST}-static DESTINATION lib)
+
+ list(APPEND RDMA_STATIC_LIBS ${DEST} ${DEST}-static)
+ set(RDMA_STATIC_LIBS "${RDMA_STATIC_LIBS}" CACHE INTERNAL "")
+
+ # Create a shared library
+ add_library(${DEST} SHARED ${ARGN})
+ rdma_set_library_map(${DEST} ${VERSION_SCRIPT})
+ set_target_properties(${DEST} PROPERTIES
+ SOVERSION ${SOVERSION}
+ VERSION ${VERSION}
+ LIBRARY_OUTPUT_DIRECTORY "${BUILD_LIB}")
+ install(TARGETS ${DEST} DESTINATION lib)
+endfunction()
+
+# Create a provider shared library for libibverbs
+function(rdma_provider DEST)
+ # Installed driver file
+ install(CODE "file(MAKE_DIRECTORY \"\$ENV{DESTDIR}${CONFIG_DIR}/\")")
+ install(CODE "file(WRITE \$ENV{DESTDIR}${CONFIG_DIR}/${DEST}.driver \"driver ${DEST}\\n\")")
+
+ # Uninstalled driver file
+ file(MAKE_DIRECTORY "${BUILD_LIB}/libibverbs.d/")
+ file(WRITE "${BUILD_LIB}/libibverbs.d/${DEST}.driver" "driver ${BUILD_LIB}/${DEST}\n")
+
+ # FIXME: This symlink is provided for compat with the old build, but it
+ # never should have existed in the first place, nothing should use this
+ # name, we can probably remove it.
+ install(CODE "execute_process(COMMAND ln -sTf lib${DEST}-rdmav2.so \"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/lib${DEST}.so\")")
+
+ # Create a static provider library
+ add_library(${DEST} STATIC ${ARGN})
+ set_target_properties(${DEST} PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${BUILD_LIB}")
+ install(TARGETS ${DEST} DESTINATION lib)
+
+ list(APPEND RDMA_STATIC_LIBS ${DEST}-rdmav2 ${DEST})
+ set(RDMA_STATIC_LIBS "${RDMA_STATIC_LIBS}" CACHE INTERNAL "")
+
+ # Create the plugin shared library
+ set(DEST ${DEST}-rdmav2)
+ add_library(${DEST} MODULE ${ARGN})
+ rdma_set_library_map(${DEST} ${BUILDLIB}/provider.map)
+ target_link_libraries(${DEST} PRIVATE ibverbs)
+ target_link_libraries(${DEST} PRIVATE ${CMAKE_THREAD_LIBS_INIT})
+ set_target_properties(${DEST} PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${BUILD_LIB}")
+ # Provider Plugins do not use SONAME versioning, there is no reason to
+ # create the usual symlinks.
+
+ install(TARGETS ${DEST} DESTINATION lib)
+endfunction()
+
+ # Create an installed executable
+function(rdma_executable EXEC)
+ add_executable(${EXEC} ${ARGN})
+ set_target_properties(${EXEC} PROPERTIES RUNTIME_OUTPUT_DIRECTORY "${BUILD_BIN}")
+ install(TARGETS ${EXEC} DESTINATION bin)
+endfunction()
+
+# Create an test executable (not-installed)
+function(rdma_test_executable EXEC)
+ add_executable(${EXEC} ${ARGN})
+ set_target_properties(${EXEC} PROPERTIES RUNTIME_OUTPUT_DIRECTORY "${BUILD_BIN}")
+endfunction()
+
+# Install man pages. This deduces the section from the trailing integer in the
+# filename
+function(rdma_man_pages)
+ foreach(I ${ARGN})
+ string(REGEX REPLACE "^.+[.](.+)$" "\\1" MAN_SECT ${I})
+ install(FILES ${I} DESTINATION "share/man/man${MAN_SECT}/")
+ endforeach()
+endfunction()
+
+# Create an alias for a man page, using a symlink.
+# Input is a list of pairs of names (MAN_PAGE ALIAS)
+# NOTE: The section must currently be the same for both.
+function(rdma_alias_man_pages)
+ list(LENGTH ARGN LEN)
+ math(EXPR LEN ${LEN}-1)
+ foreach(I RANGE 0 ${LEN} 2)
+ list(GET ARGN ${I} FROM)
+ math(EXPR I ${I}+1)
+ list(GET ARGN ${I} TO)
+ string(REGEX REPLACE "^.+[.](.+)$" "\\1" MAN_SECT ${FROM})
+ install(CODE "execute_process(COMMAND ln -sTf ${FROM} \"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/share/man/man${MAN_SECT}/${TO}\")")
+ endforeach()
+endfunction()
+
+# For compatability write out a libtool .la file. This is only meaningful if
+# the end user is statically linking, and only if the library has dependent
+# libraries.
+
+# FIXME: it isn't clear how this is actually useful for provider libraries and
+# libibverbs itself, the user must do some trick to get the constructor to run
+# in the provider, at least how to do that should be documented someplace..
+function(rdma_make_libtool_la SHARED STATIC LIBS)
+ get_property(LIB TARGET ${STATIC} PROPERTY OUTPUT_NAME SET)
+ if (LIB)
+ get_target_property(LIB ${STATIC} OUTPUT_NAME)
+ else()
+ set(LIB ${STATIC})
+ endif()
+
+ set(BARE_LAFN "${CMAKE_STATIC_LIBRARY_PREFIX}${LIB}.la")
+ set(BARE_LIBFN "${CMAKE_STATIC_LIBRARY_PREFIX}${LIB}${CMAKE_STATIC_LIBRARY_SUFFIX}")
+
+ get_property(SOLIB TARGET ${SHARED} PROPERTY OUTPUT_NAME SET)
+ if (SOLIB)
+ get_target_property(SOLIB ${SHARED} OUTPUT_NAME)
+ else()
+ set(SOLIB ${SHARED})
+ endif()
+
+ set(DLNAME "${CMAKE_SHARED_LIBRARY_PREFIX}${SOLIB}${CMAKE_SHARED_LIBRARY_SUFFIX}")
+ get_property(TMP TARGET ${SHARED} PROPERTY SOVERSION SET)
+ if (TMP)
+ get_target_property(VERSION ${SHARED} VERSION)
+ get_target_property(SOVERSION ${SHARED} SOVERSION)
+ set(NAMES "${DLNAME}.${VERSION} ${DLNAME}.${SOVERSION} ${DLNAME}")
+ set(DLNAME "${DLNAME}.${SOVERSION}")
+ else()
+ set(NAMES "${DLNAME}")
+ set(DLNAME "${CMAKE_SHARED_LIBRARY_PREFIX}${SOLIB}${CMAKE_SHARED_LIBRARY_SUFFIX}")
+ endif()
+
+ if (LIBS)
+ list(REMOVE_DUPLICATES LIBS)
+ foreach(I ${LIBS})
+ if (I MATCHES "^-l")
+ list(APPEND DEPS "${I}")
+ else()
+ list(APPEND DEPS "-l${I}")
+ endif()
+ endforeach()
+ string(REPLACE ";" " " DEPS "${DEPS}")
+ endif()
+
+ set(LAFN "${BUILD_LIB}/${BARE_LAFN}")
+ file(WRITE ${LAFN}
+ "# ${BARE_LAFN} - a libtool library file\n"
+ "# Generated by cmake\n"
+ "#\n"
+ "# Please DO NOT delete this file!\n"
+ "# It is necessary for linking the library.\n"
+ "\n"
+ "# The name that we can dlopen(3).\n"
+ "dlname='${DLNAME}'\n"
+ "\n"
+ "# Names of this library.\n"
+ "library_names='${NAMES}'\n"
+ "\n"
+ "# The name of the static archive.\n"
+ "old_library='${BARE_LIBFN}'\n"
+ "\n"
+ "# Linker flags that can not go in dependency_libs.\n"
+ "inherited_linker_flags=''\n"
+ "\n"
+ "# Libraries that this one depends upon.\n"
+ "dependency_libs='${DEPS}'\n"
+ "\n"
+ "# Names of additional weak libraries provided by this library\n"
+ "weak_library_names=''\n"
+ "\n"
+ "# Version information for ${CMAKE_STATIC_LIBRARY_PREFIX}${LIB}.\n"
+ # We don't try very hard to emulate this, it isn't used for static linking anyhow
+ "current=${SOVERSION}\n"
+ "age=0\n"
+ "revision=0\n"
+ "\n"
+ "# Is this an already installed library?\n"
+ "installed=yes\n"
+ "\n"
+ "# Should we warn about portability when linking against -modules?\n"
+ "shouldnotlink=no\n"
+ "\n"
+ "# Files to dlopen/dlpreopen\n"
+ "dlopen=''\n"
+ "dlpreopen=''\n"
+ "\n"
+ "# Directory that this library needs to be installed in:\n"
+ "libdir='${CMAKE_INSTALL_PREFIX}/lib'\n"
+ )
+ install(FILES ${LAFN} DESTINATION "lib/")
+endfunction()
+
+# Finalize the setup of the static libraries by copying the meta information
+# from the shared and setting up the libtool .la files.
+function(rdma_finalize_libs)
+ list(LENGTH RDMA_STATIC_LIBS LEN)
+ math(EXPR LEN ${LEN}-1)
+ foreach(I RANGE 0 ${LEN} 2)
+ list(GET RDMA_STATIC_LIBS ${I} SHARED)
+ math(EXPR I ${I}+1)
+ list(GET RDMA_STATIC_LIBS ${I} STATIC)
+
+ # PUBLIC libraries
+ get_property(TMP TARGET ${SHARED} PROPERTY INTERFACE_LINK_LIBRARIES SET)
+ if (TMP)
+ get_target_property(TMP ${SHARED} INTERFACE_LINK_LIBRARIES)
+ set_target_properties(${STATIC} PROPERTIES INTERFACE_LINK_LIBRARIES "${TMP}")
+ set(LIBS "${TMP}")
+ endif()
+
+ # PRIVATE libraries
+ get_property(TMP TARGET ${SHARED} PROPERTY LINK_LIBRARIES SET)
+ if (TMP)
+ get_target_property(TMP ${SHARED} LINK_LIBRARIES)
+ set_target_properties(${STATIC} PROPERTIES LINK_LIBRARIES "${TMP}")
+ list(APPEND LIBS "${TMP}")
+ endif()
+
+ rdma_make_libtool_la(${SHARED} ${STATIC} "${LIBS}")
+ endforeach()
+endfunction()
diff --git a/libcxgb3/src/CMakeLists.txt b/libcxgb3/src/CMakeLists.txt
new file mode 100644
index 000000000000..a578105e7b28
--- /dev/null
+++ b/libcxgb3/src/CMakeLists.txt
@@ -0,0 +1,6 @@
+rdma_provider(cxgb3
+ cq.c
+ iwch.c
+ qp.c
+ verbs.c
+)
diff --git a/libcxgb4/src/CMakeLists.txt b/libcxgb4/src/CMakeLists.txt
new file mode 100644
index 000000000000..79da381210e6
--- /dev/null
+++ b/libcxgb4/src/CMakeLists.txt
@@ -0,0 +1,6 @@
+rdma_provider(cxgb4
+ cq.c
+ dev.c
+ qp.c
+ verbs.c
+)
diff --git a/libhfi1verbs/src/CMakeLists.txt b/libhfi1verbs/src/CMakeLists.txt
new file mode 100644
index 000000000000..702bb5e23b30
--- /dev/null
+++ b/libhfi1verbs/src/CMakeLists.txt
@@ -0,0 +1,4 @@
+rdma_provider(hfi1verbs
+ hfiverbs.c
+ verbs.c
+ )
diff --git a/libi40iw/src/CMakeLists.txt b/libi40iw/src/CMakeLists.txt
new file mode 100644
index 000000000000..d8a3a3c2c414
--- /dev/null
+++ b/libi40iw/src/CMakeLists.txt
@@ -0,0 +1,5 @@
+rdma_provider(i40iw
+ i40iw_uk.c
+ i40iw_umain.c
+ i40iw_uverbs.c
+)
diff --git a/libibcm/examples/CMakeLists.txt b/libibcm/examples/CMakeLists.txt
new file mode 100644
index 000000000000..a90639dae768
--- /dev/null
+++ b/libibcm/examples/CMakeLists.txt
@@ -0,0 +1,2 @@
+rdma_test_executable(cmpost cmpost.c)
+target_link_libraries(cmpost ibcm rdmacm)
diff --git a/libibcm/src/CMakeLists.txt b/libibcm/src/CMakeLists.txt
new file mode 100644
index 000000000000..01f85c0ea638
--- /dev/null
+++ b/libibcm/src/CMakeLists.txt
@@ -0,0 +1,9 @@
+publish_headers(infiniband
+ ../include/infiniband/cm.h
+ ../include/infiniband/cm_abi.h
+ )
+
+rdma_library(ibcm libibcm.map 1 1.0.0
+ cm.c
+ )
+target_link_libraries(ibcm PUBLIC ibverbs)
diff --git a/libibumad/man/CMakeLists.txt b/libibumad/man/CMakeLists.txt
new file mode 100644
index 000000000000..b7a191261ec0
--- /dev/null
+++ b/libibumad/man/CMakeLists.txt
@@ -0,0 +1,42 @@
+rdma_man_pages(
+ umad_addr_dump.3
+ umad_alloc.3
+ umad_attribute_str.3
+ umad_class_str.3
+ umad_close_port.3
+ umad_debug.3
+ umad_dump.3
+ umad_free.3
+ umad_get_ca.3
+ umad_get_ca_portguids.3
+ umad_get_cas_names.3
+ umad_get_fd.3
+ umad_get_issm_path.3
+ umad_get_mad.3
+ umad_get_mad_addr.3
+ umad_get_pkey.3
+ umad_get_port.3
+ umad_init.3
+ umad_mad_status_str.3
+ umad_method_str.3
+ umad_open_port.3
+ umad_poll.3
+ umad_recv.3
+ umad_register.3
+ umad_register2.3
+ umad_register_oui.3
+ umad_send.3
+ umad_set_addr.3
+ umad_set_addr_net.3
+ umad_set_grh.3
+ umad_set_grh_net.3
+ umad_set_pkey.3
+ umad_size.3
+ umad_status.3
+ umad_unregister.3
+ )
+rdma_alias_man_pages(
+ umad_get_ca.3 umad_release_ca.3
+ umad_get_port.3 umad_release_port.3
+ umad_init.3 umad_done.3
+ )
\ No newline at end of file
diff --git a/libibumad/src/CMakeLists.txt b/libibumad/src/CMakeLists.txt
new file mode 100644
index 000000000000..b7b5d03bc53e
--- /dev/null
+++ b/libibumad/src/CMakeLists.txt
@@ -0,0 +1,14 @@
+publish_headers(infiniband
+ ../include/infiniband/umad.h
+ ../include/infiniband/umad_cm.h
+ ../include/infiniband/umad_sa.h
+ ../include/infiniband/umad_sm.h
+ ../include/infiniband/umad_str.h
+ ../include/infiniband/umad_types.h
+ )
+
+rdma_library(ibumad libibumad.map 3 3.1.0
+ sysfs.c
+ umad.c
+ umad_str.c
+ )
diff --git a/libibumad/tests/CMakeLists.txt b/libibumad/tests/CMakeLists.txt
new file mode 100644
index 000000000000..9676029c8688
--- /dev/null
+++ b/libibumad/tests/CMakeLists.txt
@@ -0,0 +1,5 @@
+rdma_test_executable(umad_reg2 umad_reg2_compat.c)
+target_link_libraries(umad_reg2 ibumad)
+
+rdma_test_executable(umad_register2 umad_register2.c)
+target_link_libraries(umad_register2 ibumad)
diff --git a/libibverbs/examples/CMakeLists.txt b/libibverbs/examples/CMakeLists.txt
new file mode 100644
index 000000000000..5d0df01ca959
--- /dev/null
+++ b/libibverbs/examples/CMakeLists.txt
@@ -0,0 +1,29 @@
+# Shared example files
+add_library(ibverbs_tools STATIC
+ pingpong.c
+ )
+
+rdma_executable(ibv_asyncwatch asyncwatch.c)
+target_link_libraries(ibv_asyncwatch ibverbs)
+
+rdma_executable(ibv_devices device_list.c)
+target_link_libraries(ibv_devices ibverbs)
+
+rdma_executable(ibv_devinfo devinfo.c)
+target_link_libraries(ibv_devinfo ibverbs)
+
+# FIXME: pingpong.o should be a object library
+rdma_executable(ibv_rc_pingpong rc_pingpong.c)
+target_link_libraries(ibv_rc_pingpong ibverbs ibverbs_tools)
+
+rdma_executable(ibv_srq_pingpong srq_pingpong.c)
+target_link_libraries(ibv_srq_pingpong ibverbs ibverbs_tools)
+
+rdma_executable(ibv_uc_pingpong uc_pingpong.c)
+target_link_libraries(ibv_uc_pingpong ibverbs ibverbs_tools)
+
+rdma_executable(ibv_ud_pingpong ud_pingpong.c)
+target_link_libraries(ibv_ud_pingpong ibverbs ibverbs_tools)
+
+rdma_executable(ibv_xsrq_pingpong xsrq_pingpong.c)
+target_link_libraries(ibv_xsrq_pingpong ibverbs ibverbs_tools)
diff --git a/libibverbs/man/CMakeLists.txt b/libibverbs/man/CMakeLists.txt
new file mode 100644
index 000000000000..e9d757a77f34
--- /dev/null
+++ b/libibverbs/man/CMakeLists.txt
@@ -0,0 +1,78 @@
+rdma_man_pages(
+ ibv_alloc_mw.3
+ ibv_alloc_pd.3
+ ibv_asyncwatch.1
+ ibv_attach_mcast.3
+ ibv_bind_mw.3
+ ibv_create_ah.3
+ ibv_create_ah_from_wc.3
+ ibv_create_comp_channel.3
+ ibv_create_cq.3
+ ibv_create_cq_ex.3
+ ibv_create_flow.3
+ ibv_create_qp.3
+ ibv_create_qp_ex.3
+ ibv_create_srq.3
+ ibv_create_srq_ex.3
+ ibv_devices.1
+ ibv_devinfo.1
+ ibv_event_type_str.3
+ ibv_fork_init.3
+ ibv_get_async_event.3
+ ibv_get_cq_event.3
+ ibv_get_device_guid.3
+ ibv_get_device_list.3
+ ibv_get_device_name.3
+ ibv_get_srq_num.3
+ ibv_inc_rkey.3
+ ibv_modify_qp.3
+ ibv_modify_srq.3
+ ibv_open_device.3
+ ibv_open_qp.3
+ ibv_open_xrcd.3
+ ibv_poll_cq.3
+ ibv_post_recv.3
+ ibv_post_send.3
+ ibv_post_srq_recv.3
+ ibv_query_device.3
+ ibv_query_device_ex.3
+ ibv_query_gid.3
+ ibv_query_pkey.3
+ ibv_query_port.3
+ ibv_query_qp.3
+ ibv_query_rt_values_ex.3
+ ibv_query_srq.3
+ ibv_rate_to_mbps.3
+ ibv_rate_to_mult.3
+ ibv_rc_pingpong.1
+ ibv_reg_mr.3
+ ibv_req_notify_cq.3
+ ibv_rereg_mr.3
+ ibv_resize_cq.3
+ ibv_srq_pingpong.1
+ ibv_uc_pingpong.1
+ ibv_ud_pingpong.1
+ ibv_xsrq_pingpong.1
+ )
+rdma_alias_man_pages(
+ ibv_alloc_mw.3 ibv_dealloc_mw.3
+ ibv_alloc_pd.3 ibv_dealloc_pd.3
+ ibv_attach_mcast.3 ibv_detach_mcast.3
+ ibv_create_ah.3 ibv_destroy_ah.3
+ ibv_create_ah_from_wc.3 ibv_init_ah_from_wc.3
+ ibv_create_comp_channel.3 ibv_destroy_comp_channel.3
+ ibv_create_cq.3 ibv_destroy_cq.3
+ ibv_create_flow.3 ibv_destroy_flow.3
+ ibv_create_qp.3 ibv_destroy_qp.3
+ ibv_create_srq.3 ibv_destroy_srq.3
+ ibv_event_type_str.3 ibv_node_type_str.3
+ ibv_event_type_str.3 ibv_port_state_str.3
+ ibv_get_async_event.3 ibv_ack_async_event.3
+ ibv_get_cq_event.3 ibv_ack_cq_events.3
+ ibv_get_device_list.3 ibv_free_device_list.3
+ ibv_open_device.3 ibv_close_device.3
+ ibv_open_xrcd.3 ibv_close_xrcd.3
+ ibv_rate_to_mbps.3 mbps_to_ibv_rate.3
+ ibv_rate_to_mult.3 mult_to_ibv_rate.3
+ ibv_reg_mr.3 ibv_dereg_mr.3
+ )
\ No newline at end of file
diff --git a/libibverbs/src/CMakeLists.txt b/libibverbs/src/CMakeLists.txt
new file mode 100644
index 000000000000..5e680da430c1
--- /dev/null
+++ b/libibverbs/src/CMakeLists.txt
@@ -0,0 +1,34 @@
+publish_headers(infiniband
+ ../include/infiniband/arch.h
+ ../include/infiniband/driver.h
+ ../include/infiniband/kern-abi.h
+ ../include/infiniband/marshall.h
+ ../include/infiniband/opcode.h
+ ../include/infiniband/sa-kern-abi.h
+ ../include/infiniband/sa.h
+ ../include/infiniband/verbs.h
+ )
+
+if (NOT NL_KIND EQUAL 0)
+ set(NEIGH "neigh.c")
+else()
+ set(NEIGH "")
+endif()
+
+rdma_library(ibverbs libibverbs.map 1 1.0.0
+ cmd.c
+ compat-1_0.c
+ device.c
+ enum_strs.c
+ init.c
+ marshall.c
+ memory.c
+ ${NEIGH}
+ sysfs.c
+ verbs.c
+ )
+target_link_libraries(ibverbs PRIVATE
+ ${NL_LIBRARIES}
+ ${CMAKE_THREAD_LIBS_INIT}
+ ${CMAKE_DL_LIBS}
+ )
diff --git a/libipathverbs/CMakeLists.txt b/libipathverbs/CMakeLists.txt
new file mode 100644
index 000000000000..eba006e4c409
--- /dev/null
+++ b/libipathverbs/CMakeLists.txt
@@ -0,0 +1,4 @@
+install(FILES truescale.conf DESTINATION "${SYSCONFDIR}/modprobe.d/")
+install(FILES truescale-serdes.cmds
+ DESTINATION "sbin/"
+ PERMISSIONS OWNER_WRITE OWNER_READ GROUP_READ WORLD_READ OWNER_EXECUTE GROUP_EXECUTE WORLD_EXECUTE)
diff --git a/libipathverbs/src/CMakeLists.txt b/libipathverbs/src/CMakeLists.txt
new file mode 100644
index 000000000000..20924fda7900
--- /dev/null
+++ b/libipathverbs/src/CMakeLists.txt
@@ -0,0 +1,4 @@
+rdma_provider(ipathverbs
+ ipathverbs.c
+ verbs.c
+ )
diff --git a/libmlx4/src/CMakeLists.txt b/libmlx4/src/CMakeLists.txt
new file mode 100644
index 000000000000..d64d817479bf
--- /dev/null
+++ b/libmlx4/src/CMakeLists.txt
@@ -0,0 +1,9 @@
+rdma_provider(mlx4
+ buf.c
+ cq.c
+ dbrec.c
+ mlx4.c
+ qp.c
+ srq.c
+ verbs.c
+)
diff --git a/libmlx5/src/CMakeLists.txt b/libmlx5/src/CMakeLists.txt
new file mode 100644
index 000000000000..a34a8063eeb2
--- /dev/null
+++ b/libmlx5/src/CMakeLists.txt
@@ -0,0 +1,9 @@
+rdma_provider(mlx5
+ buf.c
+ cq.c
+ dbrec.c
+ mlx5.c
+ qp.c
+ srq.c
+ verbs.c
+)
diff --git a/libmthca/src/CMakeLists.txt b/libmthca/src/CMakeLists.txt
new file mode 100644
index 000000000000..63d714704144
--- /dev/null
+++ b/libmthca/src/CMakeLists.txt
@@ -0,0 +1,10 @@
+rdma_provider(mthca
+ ah.c
+ buf.c
+ cq.c
+ memfree.c
+ mthca.c
+ qp.c
+ srq.c
+ verbs.c
+)
diff --git a/libnes/src/CMakeLists.txt b/libnes/src/CMakeLists.txt
new file mode 100644
index 000000000000..0c7fa8fad09f
--- /dev/null
+++ b/libnes/src/CMakeLists.txt
@@ -0,0 +1,4 @@
+rdma_provider(nes
+ nes_umain.c
+ nes_uverbs.c
+)
diff --git a/libocrdma/src/CMakeLists.txt b/libocrdma/src/CMakeLists.txt
new file mode 100644
index 000000000000..08623adb4a6f
--- /dev/null
+++ b/libocrdma/src/CMakeLists.txt
@@ -0,0 +1,4 @@
+rdma_provider(ocrdma
+ ocrdma_main.c
+ ocrdma_verbs.c
+ )
diff --git a/librdmacm/examples/CMakeLists.txt b/librdmacm/examples/CMakeLists.txt
new file mode 100644
index 000000000000..31c9606383a0
--- /dev/null
+++ b/librdmacm/examples/CMakeLists.txt
@@ -0,0 +1,43 @@
+# Shared example files
+add_library(rdmacm_tools STATIC
+ common.c
+ )
+
+rdma_executable(cmtime cmtime.c)
+target_link_libraries(cmtime rdmacm ${CMAKE_THREAD_LIBS_INIT} rdmacm_tools)
+
+rdma_executable(mckey mckey.c)
+target_link_libraries(mckey rdmacm ${CMAKE_THREAD_LIBS_INIT})
+
+rdma_executable(rcopy rcopy.c)
+target_link_libraries(rcopy rdmacm)
+
+rdma_executable(rdma_client rdma_client.c)
+target_link_libraries(rdma_client rdmacm)
+
+rdma_executable(rdma_server rdma_server.c)
+target_link_libraries(rdma_server rdmacm)
+
+rdma_executable(rdma_xclient rdma_xclient.c)
+target_link_libraries(rdma_xclient rdmacm)
+
+rdma_executable(rdma_xserver rdma_xserver.c)
+target_link_libraries(rdma_xserver rdmacm)
+
+rdma_executable(riostream riostream.c)
+target_link_libraries(riostream rdmacm rdmacm_tools)
+
+rdma_executable(rping rping.c)
+target_link_libraries(rping rdmacm ${CMAKE_THREAD_LIBS_INIT})
+
+rdma_executable(rstream rstream.c)
+target_link_libraries(rstream rdmacm rdmacm_tools)
+
+rdma_executable(ucmatose cmatose.c)
+target_link_libraries(ucmatose rdmacm rdmacm_tools)
+
+rdma_executable(udaddy udaddy.c)
+target_link_libraries(udaddy rdmacm rdmacm_tools)
+
+rdma_executable(udpong udpong.c)
+target_link_libraries(udpong rdmacm rdmacm_tools)
diff --git a/librdmacm/man/CMakeLists.txt b/librdmacm/man/CMakeLists.txt
new file mode 100644
index 000000000000..791c98265ad0
--- /dev/null
+++ b/librdmacm/man/CMakeLists.txt
@@ -0,0 +1,65 @@
+rdma_man_pages(
+ mckey.1
+ rcopy.1
+ rdma_accept.3
+ rdma_ack_cm_event.3
+ rdma_bind_addr.3
+ rdma_client.1
+ rdma_cm.7
+ rdma_connect.3
+ rdma_create_ep.3
+ rdma_create_event_channel.3
+ rdma_create_id.3
+ rdma_create_qp.3
+ rdma_create_srq.3
+ rdma_dereg_mr.3
+ rdma_destroy_ep.3
+ rdma_destroy_event_channel.3
+ rdma_destroy_id.3
+ rdma_destroy_qp.3
+ rdma_destroy_srq.3
+ rdma_disconnect.3
+ rdma_event_str.3
+ rdma_free_devices.3
+ rdma_get_cm_event.3
+ rdma_get_devices.3
+ rdma_get_dst_port.3
+ rdma_get_local_addr.3
+ rdma_get_peer_addr.3
+ rdma_get_recv_comp.3
+ rdma_get_request.3
+ rdma_get_send_comp.3
+ rdma_get_src_port.3
+ rdma_getaddrinfo.3
+ rdma_join_multicast.3
+ rdma_leave_multicast.3
+ rdma_listen.3
+ rdma_migrate_id.3
+ rdma_notify.3
+ rdma_post_read.3
+ rdma_post_readv.3
+ rdma_post_recv.3
+ rdma_post_recvv.3
+ rdma_post_send.3
+ rdma_post_sendv.3
+ rdma_post_ud_send.3
+ rdma_post_write.3
+ rdma_post_writev.3
+ rdma_reg_msgs.3
+ rdma_reg_read.3
+ rdma_reg_write.3
+ rdma_reject.3
+ rdma_resolve_addr.3
+ rdma_resolve_route.3
+ rdma_server.1
+ rdma_set_option.3
+ rdma_xclient.1
+ rdma_xserver.1
+ riostream.1
+ rping.1
+ # FIXME: rsocket has a text substitution but nothing ever filled it in.
+ rsocket.7
+ rstream.1
+ ucmatose.1
+ udaddy.1
+ )
diff --git a/librdmacm/src/CMakeLists.txt b/librdmacm/src/CMakeLists.txt
new file mode 100644
index 000000000000..c68b277f8c1c
--- /dev/null
+++ b/librdmacm/src/CMakeLists.txt
@@ -0,0 +1,39 @@
+publish_headers(rdma
+ ../include/rdma/rdma_cma.h
+ ../include/rdma/rdma_cma_abi.h
+ ../include/rdma/rdma_verbs.h
+ ../include/rdma/rsocket.h
+ )
+publish_headers(infiniband
+ ../include/infiniband/ib.h
+ )
+
+rdma_library(rdmacm librdmacm.map 1 1.0.0
+ acm.c
+ addrinfo.c
+ cma.c
+ indexer.c
+ rsocket.c
+ )
+target_link_libraries(rdmacm PUBLIC ibverbs)
+target_link_libraries(rdmacm PRIVATE ${CMAKE_THREAD_LIBS_INIT})
+
+# The preload library is a bit special, it needs to be open coded
+# Since it is a LD_PRELOAD it has no soname, and is installed in sub dir
+add_library(rspreload SHARED
+ preload.c
+ indexer.c
+ )
+set_target_properties(rspreload PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${BUILD_LIB}")
+rdma_set_library_map(rspreload librspreload.map)
+target_link_libraries(rspreload PRIVATE
+ rdmacm
+ ${CMAKE_THREAD_LIBS_INIT}
+ ${CMAKE_DL_LIBS}
+)
+install(TARGETS rspreload DESTINATION lib/rsocket/)
+
+# These are for compat with old packaging, these name should not be used.
+# FIXME: Maybe we can get rid of them?
+install(CODE "execute_process(COMMAND ln -sTf librspreload.so \"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/rsocket/librspreload.so.1\")")
+install(CODE "execute_process(COMMAND ln -sTf librspreload.so \"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/lib/rsocket/librspreload.so.1.0.0\")")
diff --git a/librxe/CMakeLists.txt b/librxe/CMakeLists.txt
new file mode 100644
index 000000000000..d736c67e53d9
--- /dev/null
+++ b/librxe/CMakeLists.txt
@@ -0,0 +1,4 @@
+install(FILES rxe_cfg
+ DESTINATION bin/
+ PERMISSIONS OWNER_WRITE OWNER_READ GROUP_READ WORLD_READ OWNER_EXECUTE GROUP_EXECUTE WORLD_EXECUTE
+ )
diff --git a/librxe/man/CMakeLists.txt b/librxe/man/CMakeLists.txt
new file mode 100644
index 000000000000..69e8bd8cf20c
--- /dev/null
+++ b/librxe/man/CMakeLists.txt
@@ -0,0 +1,4 @@
+rdma_man_pages(
+ rxe.7
+ rxe_cfg.8
+)
diff --git a/librxe/src/CMakeLists.txt b/librxe/src/CMakeLists.txt
new file mode 100644
index 000000000000..d8f3265176e4
--- /dev/null
+++ b/librxe/src/CMakeLists.txt
@@ -0,0 +1,3 @@
+rdma_provider(rxe
+ rxe.c
+ )
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 09/15] Support obsolete cmake from 2013
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (7 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 08/15] Unified CMake build system Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 10/15] Remove the auto* based build systems Jason Gunthorpe
` (9 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
cmake 2.8.12 is also from 2013, however .12 is broadly compatible with
versions up 3.6. However, there were significant changes between .11 and .12,
such that .11 doesn't trivially work.
For some reason Centos 7 only includes 2.8.11 (Centos 6 includes .12). Even
though cmake 3.5.x is available from EPEL, make it easy for everyone and patch
in .11 support, this can be reverted someday.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
CMakeLists.txt | 2 +-
buildlib/RDMA_DoFixup.cmake | 8 ++++++--
buildlib/rdma_functions.cmake | 5 +++--
libibcm/src/CMakeLists.txt | 2 +-
libibverbs/src/CMakeLists.txt | 2 +-
librdmacm/src/CMakeLists.txt | 6 +++---
6 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 568e819aa976..4058c8a68258 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -14,7 +14,7 @@
# -DENABLE_RESOLVE_NEIGH=0 (default enabled)
# Do not link to libnl and do not resolve neighbours internally for Ethernet.
-cmake_minimum_required(VERSION 2.8.12 FATAL_ERROR)
+cmake_minimum_required(VERSION 2.8.11 FATAL_ERROR)
project(RDMA C)
set(PACKAGE_NAME "RDMA")
diff --git a/buildlib/RDMA_DoFixup.cmake b/buildlib/RDMA_DoFixup.cmake
index 1e30cf6c761b..75704ddcfe9f 100644
--- a/buildlib/RDMA_DoFixup.cmake
+++ b/buildlib/RDMA_DoFixup.cmake
@@ -3,7 +3,7 @@
# Execute a header fixup based on NOT_NEEDED for HEADER
# The buildlib includes alternate header file shims for several scenarios, if
-# the build system detects a feature is present then it should call OrcDoFixup
+# the build system detects a feature is present then it should call RDMA_DoFixup
# with the test as true. If false then the shim header will be installed.
# Typically the shim header will replace a missing header with stubs, or it
@@ -11,7 +11,11 @@
function(RDMA_DoFixup not_needed header)
set(DEST "${BUILD_INCLUDE}/${header}")
if (NOT "${not_needed}")
- get_filename_component(DIR ${DEST} DIRECTORY)
+ if(CMAKE_VERSION VERSION_LESS "2.8.12")
+ get_filename_component(DIR ${DEST} PATH)
+ else()
+ get_filename_component(DIR ${DEST} DIRECTORY)
+ endif()
file(MAKE_DIRECTORY "${DIR}")
string(REPLACE / - header-bl ${header})
execute_process(COMMAND "ln" "-Tsf" "${BUILDLIB}/fixup-include/${header-bl}" "${DEST}")
diff --git a/buildlib/rdma_functions.cmake b/buildlib/rdma_functions.cmake
index f698855563e9..34b4c7b53d19 100644
--- a/buildlib/rdma_functions.cmake
+++ b/buildlib/rdma_functions.cmake
@@ -68,8 +68,8 @@ function(rdma_provider DEST)
set(DEST ${DEST}-rdmav2)
add_library(${DEST} MODULE ${ARGN})
rdma_set_library_map(${DEST} ${BUILDLIB}/provider.map)
- target_link_libraries(${DEST} PRIVATE ibverbs)
- target_link_libraries(${DEST} PRIVATE ${CMAKE_THREAD_LIBS_INIT})
+ target_link_libraries(${DEST} LINK_PRIVATE ibverbs)
+ target_link_libraries(${DEST} LINK_PRIVATE ${CMAKE_THREAD_LIBS_INIT})
set_target_properties(${DEST} PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${BUILD_LIB}")
# Provider Plugins do not use SONAME versioning, there is no reason to
# create the usual symlinks.
@@ -222,6 +222,7 @@ function(rdma_finalize_libs)
list(GET RDMA_STATIC_LIBS ${I} STATIC)
# PUBLIC libraries
+ set(LIBS "")
get_property(TMP TARGET ${SHARED} PROPERTY INTERFACE_LINK_LIBRARIES SET)
if (TMP)
get_target_property(TMP ${SHARED} INTERFACE_LINK_LIBRARIES)
diff --git a/libibcm/src/CMakeLists.txt b/libibcm/src/CMakeLists.txt
index 01f85c0ea638..2479886c6238 100644
--- a/libibcm/src/CMakeLists.txt
+++ b/libibcm/src/CMakeLists.txt
@@ -6,4 +6,4 @@ publish_headers(infiniband
rdma_library(ibcm libibcm.map 1 1.0.0
cm.c
)
-target_link_libraries(ibcm PUBLIC ibverbs)
+target_link_libraries(ibcm LINK_PUBLIC ibverbs)
diff --git a/libibverbs/src/CMakeLists.txt b/libibverbs/src/CMakeLists.txt
index 5e680da430c1..62f962e73e97 100644
--- a/libibverbs/src/CMakeLists.txt
+++ b/libibverbs/src/CMakeLists.txt
@@ -27,7 +27,7 @@ rdma_library(ibverbs libibverbs.map 1 1.0.0
sysfs.c
verbs.c
)
-target_link_libraries(ibverbs PRIVATE
+target_link_libraries(ibverbs LINK_PRIVATE
${NL_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
${CMAKE_DL_LIBS}
diff --git a/librdmacm/src/CMakeLists.txt b/librdmacm/src/CMakeLists.txt
index c68b277f8c1c..da7ee1c95167 100644
--- a/librdmacm/src/CMakeLists.txt
+++ b/librdmacm/src/CMakeLists.txt
@@ -15,8 +15,8 @@ rdma_library(rdmacm librdmacm.map 1 1.0.0
indexer.c
rsocket.c
)
-target_link_libraries(rdmacm PUBLIC ibverbs)
-target_link_libraries(rdmacm PRIVATE ${CMAKE_THREAD_LIBS_INIT})
+target_link_libraries(rdmacm LINK_PUBLIC ibverbs)
+target_link_libraries(rdmacm LINK_PRIVATE ${CMAKE_THREAD_LIBS_INIT})
# The preload library is a bit special, it needs to be open coded
# Since it is a LD_PRELOAD it has no soname, and is installed in sub dir
@@ -26,7 +26,7 @@ add_library(rspreload SHARED
)
set_target_properties(rspreload PROPERTIES LIBRARY_OUTPUT_DIRECTORY "${BUILD_LIB}")
rdma_set_library_map(rspreload librspreload.map)
-target_link_libraries(rspreload PRIVATE
+target_link_libraries(rspreload LINK_PRIVATE
rdmacm
${CMAKE_THREAD_LIBS_INIT}
${CMAKE_DL_LIBS}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 10/15] Remove the auto* based build systems
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (8 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 09/15] Support obsolete cmake from 2013 Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 11/15] Remove the ChangeLog files Jason Gunthorpe
` (8 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
The unified cmake version provides the same functionality now.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
libcxgb3/Makefile.am | 27 -
libcxgb3/autogen.sh | 8 -
libcxgb3/config/.gitignore | 0
libcxgb3/configure.in | 69 -
libcxgb3/cxgb3.driver | 1 -
libcxgb3/src/iwch.map | 6 -
libcxgb4/Makefile.am | 27 -
libcxgb4/autogen.sh | 8 -
libcxgb4/config/config.guess | 1439 ----
libcxgb4/config/config.sub | 1811 -----
libcxgb4/config/depcomp | 530 --
libcxgb4/config/install-sh | 323 -
libcxgb4/configure.in | 69 -
libcxgb4/cxgb4.driver | 1 -
libcxgb4/src/cxgb4.map | 6 -
libhfi1verbs/Makefile.am | 83 -
libhfi1verbs/autogen.sh | 64 -
libhfi1verbs/configure.in | 126 -
libhfi1verbs/hfi1verbs.driver | 1 -
libhfi1verbs/makefile | 93 -
libhfi1verbs/makesrpm.sh | 15 -
libhfi1verbs/src/hfiverbs.map | 4 -
libi40iw/Makefile.am | 26 -
libi40iw/configure.ac | 74 -
libi40iw/i40iw.driver | 1 -
libi40iw/src/i40iw.map | 39 -
libibcm/Makefile.am | 35 -
libibcm/autogen.sh | 9 -
libibcm/configure.in | 72 -
libibumad/Makefile.am | 75 -
libibumad/autogen.sh | 11 -
libibumad/configure.in | 72 -
libibverbs/Makefile.am | 126 -
libibverbs/autogen.sh | 4 -
libibverbs/config/.gitignore | 8 -
libibverbs/configure.ac | 124 -
libipathverbs/Makefile.am | 79 -
libipathverbs/autogen.sh | 43 -
libipathverbs/configure.in | 120 -
libipathverbs/ipathverbs.driver | 1 -
libipathverbs/src/ipathverbs.map | 4 -
libmlx4/Makefile.am | 19 -
libmlx4/autogen.sh | 4 -
libmlx4/config/.gitignore | 8 -
libmlx4/configure.ac | 96 -
libmlx4/mlx4.driver | 1 -
libmlx4/src/mlx4.map | 5 -
libmlx5/Makefile.am | 27 -
libmlx5/autogen.sh | 7 -
libmlx5/config/.gitignore | 8 -
libmlx5/configure.ac | 108 -
libmlx5/m4/ax_gcc_func_attribute.m4 | 223 -
libmlx5/mlx5.driver | 1 -
libmlx5/src/mlx5.map | 5 -
libmthca/Makefile.am | 29 -
libmthca/autogen.sh | 8 -
libmthca/config/.gitignore | 8 -
libmthca/configure.in | 82 -
libmthca/mthca.driver | 1 -
libmthca/src/mthca.map | 5 -
libnes/Makefile.am | 26 -
libnes/autogen.sh | 12 -
libnes/config/.gitignore | 0
libnes/configure.in | 74 -
libnes/nes.driver | 1 -
libnes/src/nes.map | 5 -
libocrdma/Makefile.am | 23 -
libocrdma/autogen.sh | 8 -
libocrdma/config/.gitignore | 8 -
libocrdma/configure.in | 70 -
libocrdma/ocrdma.driver | 1 -
libocrdma/src/ocrdma.map | 5 -
librdmacm/Makefile.am | 141 -
librdmacm/autogen.sh | 5 -
librdmacm/configure.ac | 108 -
librxe/AUTHORS | 0
librxe/COPYING | 0
librxe/INSTALL | 0
librxe/Makefile.am | 36 -
librxe/Makefile.in | 939 ---
librxe/NEWS | 0
librxe/README | 0
librxe/aclocal.m4 | 9390 ----------------------
librxe/config.h.in | 89 -
librxe/config/config.guess | 1526 ----
librxe/config/config.sub | 1658 ----
librxe/config/depcomp | 530 --
librxe/config/install-sh | 519 --
librxe/config/ltmain.sh | 9636 ----------------------
librxe/config/missing | 360 -
librxe/configure | 14728 ----------------------------------
librxe/configure.in | 77 -
librxe/librxe.spec | 55 -
librxe/rxe.driver | 1 -
librxe/src/rxe.map | 5 -
95 files changed, 46315 deletions(-)
delete mode 100644 libcxgb3/Makefile.am
delete mode 100755 libcxgb3/autogen.sh
delete mode 100644 libcxgb3/config/.gitignore
delete mode 100644 libcxgb3/configure.in
delete mode 100644 libcxgb3/cxgb3.driver
delete mode 100644 libcxgb3/src/iwch.map
delete mode 100644 libcxgb4/Makefile.am
delete mode 100755 libcxgb4/autogen.sh
delete mode 100755 libcxgb4/config/config.guess
delete mode 100755 libcxgb4/config/config.sub
delete mode 100755 libcxgb4/config/depcomp
delete mode 100755 libcxgb4/config/install-sh
delete mode 100644 libcxgb4/configure.in
delete mode 100644 libcxgb4/cxgb4.driver
delete mode 100644 libcxgb4/src/cxgb4.map
delete mode 100644 libhfi1verbs/Makefile.am
delete mode 100755 libhfi1verbs/autogen.sh
delete mode 100644 libhfi1verbs/configure.in
delete mode 100644 libhfi1verbs/hfi1verbs.driver
delete mode 100644 libhfi1verbs/makefile
delete mode 100644 libhfi1verbs/makesrpm.sh
delete mode 100644 libhfi1verbs/src/hfiverbs.map
delete mode 100644 libi40iw/Makefile.am
delete mode 100644 libi40iw/configure.ac
delete mode 100644 libi40iw/i40iw.driver
delete mode 100644 libi40iw/src/i40iw.map
delete mode 100644 libibcm/Makefile.am
delete mode 100755 libibcm/autogen.sh
delete mode 100644 libibcm/configure.in
delete mode 100644 libibumad/Makefile.am
delete mode 100755 libibumad/autogen.sh
delete mode 100644 libibumad/configure.in
delete mode 100644 libibverbs/Makefile.am
delete mode 100755 libibverbs/autogen.sh
delete mode 100644 libibverbs/config/.gitignore
delete mode 100644 libibverbs/configure.ac
delete mode 100644 libipathverbs/Makefile.am
delete mode 100755 libipathverbs/autogen.sh
delete mode 100644 libipathverbs/configure.in
delete mode 100644 libipathverbs/ipathverbs.driver
delete mode 100644 libipathverbs/src/ipathverbs.map
delete mode 100644 libmlx4/Makefile.am
delete mode 100755 libmlx4/autogen.sh
delete mode 100644 libmlx4/config/.gitignore
delete mode 100644 libmlx4/configure.ac
delete mode 100644 libmlx4/mlx4.driver
delete mode 100644 libmlx4/src/mlx4.map
delete mode 100644 libmlx5/Makefile.am
delete mode 100755 libmlx5/autogen.sh
delete mode 100644 libmlx5/config/.gitignore
delete mode 100644 libmlx5/configure.ac
delete mode 100644 libmlx5/m4/ax_gcc_func_attribute.m4
delete mode 100644 libmlx5/mlx5.driver
delete mode 100644 libmlx5/src/mlx5.map
delete mode 100644 libmthca/Makefile.am
delete mode 100755 libmthca/autogen.sh
delete mode 100644 libmthca/config/.gitignore
delete mode 100644 libmthca/configure.in
delete mode 100644 libmthca/mthca.driver
delete mode 100644 libmthca/src/mthca.map
delete mode 100644 libnes/Makefile.am
delete mode 100755 libnes/autogen.sh
delete mode 100644 libnes/config/.gitignore
delete mode 100644 libnes/configure.in
delete mode 100644 libnes/nes.driver
delete mode 100644 libnes/src/nes.map
delete mode 100644 libocrdma/Makefile.am
delete mode 100644 libocrdma/autogen.sh
delete mode 100644 libocrdma/config/.gitignore
delete mode 100644 libocrdma/configure.in
delete mode 100644 libocrdma/ocrdma.driver
delete mode 100644 libocrdma/src/ocrdma.map
delete mode 100644 librdmacm/Makefile.am
delete mode 100755 librdmacm/autogen.sh
delete mode 100644 librdmacm/configure.ac
delete mode 100644 librxe/AUTHORS
delete mode 100644 librxe/COPYING
delete mode 100644 librxe/INSTALL
delete mode 100644 librxe/Makefile.am
delete mode 100644 librxe/Makefile.in
delete mode 100644 librxe/NEWS
delete mode 100644 librxe/README
delete mode 100644 librxe/aclocal.m4
delete mode 100644 librxe/config.h.in
delete mode 100755 librxe/config/config.guess
delete mode 100755 librxe/config/config.sub
delete mode 100755 librxe/config/depcomp
delete mode 100755 librxe/config/install-sh
delete mode 100755 librxe/config/ltmain.sh
delete mode 100755 librxe/config/missing
delete mode 100755 librxe/configure
delete mode 100644 librxe/configure.in
delete mode 100644 librxe/librxe.spec
delete mode 100644 librxe/rxe.driver
delete mode 100644 librxe/src/rxe.map
diff --git a/libcxgb3/Makefile.am b/libcxgb3/Makefile.am
deleted file mode 100644
index 99f1cae08531..000000000000
diff --git a/libcxgb3/autogen.sh b/libcxgb3/autogen.sh
deleted file mode 100755
index fd47839cae8c..000000000000
diff --git a/libcxgb3/config/.gitignore b/libcxgb3/config/.gitignore
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/libcxgb3/configure.in b/libcxgb3/configure.in
deleted file mode 100644
index db9177230cae..000000000000
diff --git a/libcxgb3/cxgb3.driver b/libcxgb3/cxgb3.driver
deleted file mode 100644
index cfa6186bf714..000000000000
diff --git a/libcxgb3/src/iwch.map b/libcxgb3/src/iwch.map
deleted file mode 100644
index 59a8baead48f..000000000000
diff --git a/libcxgb4/Makefile.am b/libcxgb4/Makefile.am
deleted file mode 100644
index f75d9641ce12..000000000000
diff --git a/libcxgb4/autogen.sh b/libcxgb4/autogen.sh
deleted file mode 100755
index fd47839cae8c..000000000000
diff --git a/libcxgb4/config/config.guess b/libcxgb4/config/config.guess
deleted file mode 100755
index 61754411ea95..000000000000
diff --git a/libcxgb4/config/config.sub b/libcxgb4/config/config.sub
deleted file mode 100755
index 16cd209d75ed..000000000000
diff --git a/libcxgb4/config/depcomp b/libcxgb4/config/depcomp
deleted file mode 100755
index 04701da536f3..000000000000
diff --git a/libcxgb4/config/install-sh b/libcxgb4/config/install-sh
deleted file mode 100755
index 4d4a9519eaf8..000000000000
diff --git a/libcxgb4/configure.in b/libcxgb4/configure.in
deleted file mode 100644
index 336ab1c57daf..000000000000
diff --git a/libcxgb4/cxgb4.driver b/libcxgb4/cxgb4.driver
deleted file mode 100644
index e041cb24c610..000000000000
diff --git a/libcxgb4/src/cxgb4.map b/libcxgb4/src/cxgb4.map
deleted file mode 100644
index 59a8baead48f..000000000000
diff --git a/libhfi1verbs/Makefile.am b/libhfi1verbs/Makefile.am
deleted file mode 100644
index d86ea3dd57e6..000000000000
diff --git a/libhfi1verbs/autogen.sh b/libhfi1verbs/autogen.sh
deleted file mode 100755
index 738b034eb59a..000000000000
diff --git a/libhfi1verbs/configure.in b/libhfi1verbs/configure.in
deleted file mode 100644
index 3f6e6779ce74..000000000000
diff --git a/libhfi1verbs/hfi1verbs.driver b/libhfi1verbs/hfi1verbs.driver
deleted file mode 100644
index 3ceb7ee85afb..000000000000
diff --git a/libhfi1verbs/makefile b/libhfi1verbs/makefile
deleted file mode 100644
index e7661ddc7bad..000000000000
diff --git a/libhfi1verbs/makesrpm.sh b/libhfi1verbs/makesrpm.sh
deleted file mode 100644
index 3fafb418f472..000000000000
diff --git a/libhfi1verbs/src/hfiverbs.map b/libhfi1verbs/src/hfiverbs.map
deleted file mode 100644
index d3517dd0f59b..000000000000
diff --git a/libi40iw/Makefile.am b/libi40iw/Makefile.am
deleted file mode 100644
index 98d6f8ae1226..000000000000
diff --git a/libi40iw/configure.ac b/libi40iw/configure.ac
deleted file mode 100644
index e3849b03561b..000000000000
diff --git a/libi40iw/i40iw.driver b/libi40iw/i40iw.driver
deleted file mode 100644
index 7dab2f03b9e9..000000000000
diff --git a/libi40iw/src/i40iw.map b/libi40iw/src/i40iw.map
deleted file mode 100644
index 112420a1d1c1..000000000000
diff --git a/libibcm/Makefile.am b/libibcm/Makefile.am
deleted file mode 100644
index ff0b1ded12a3..000000000000
diff --git a/libibcm/autogen.sh b/libibcm/autogen.sh
deleted file mode 100755
index f433312161d2..000000000000
diff --git a/libibcm/configure.in b/libibcm/configure.in
deleted file mode 100644
index 145e3a4cebf2..000000000000
diff --git a/libibumad/Makefile.am b/libibumad/Makefile.am
deleted file mode 100644
index 1dddf7bb2ffd..000000000000
diff --git a/libibumad/autogen.sh b/libibumad/autogen.sh
deleted file mode 100755
index 4827884ba1f1..000000000000
diff --git a/libibumad/configure.in b/libibumad/configure.in
deleted file mode 100644
index 0b2794baad40..000000000000
diff --git a/libibverbs/Makefile.am b/libibverbs/Makefile.am
deleted file mode 100644
index 5349314c53a9..000000000000
diff --git a/libibverbs/autogen.sh b/libibverbs/autogen.sh
deleted file mode 100755
index 6c9233e01a60..000000000000
diff --git a/libibverbs/config/.gitignore b/libibverbs/config/.gitignore
deleted file mode 100644
index 4d4c7b1710b0..000000000000
diff --git a/libibverbs/configure.ac b/libibverbs/configure.ac
deleted file mode 100644
index a8046f3c5a72..000000000000
diff --git a/libipathverbs/Makefile.am b/libipathverbs/Makefile.am
deleted file mode 100644
index 4d3e9258d989..000000000000
diff --git a/libipathverbs/autogen.sh b/libipathverbs/autogen.sh
deleted file mode 100755
index 493c586fdef7..000000000000
diff --git a/libipathverbs/configure.in b/libipathverbs/configure.in
deleted file mode 100644
index f2cf2e3f90ee..000000000000
diff --git a/libipathverbs/ipathverbs.driver b/libipathverbs/ipathverbs.driver
deleted file mode 100644
index d2125786170b..000000000000
diff --git a/libipathverbs/src/ipathverbs.map b/libipathverbs/src/ipathverbs.map
deleted file mode 100644
index d3517dd0f59b..000000000000
diff --git a/libmlx4/Makefile.am b/libmlx4/Makefile.am
deleted file mode 100644
index 9bb90e964fe9..000000000000
diff --git a/libmlx4/autogen.sh b/libmlx4/autogen.sh
deleted file mode 100755
index 6c9233e01a60..000000000000
diff --git a/libmlx4/config/.gitignore b/libmlx4/config/.gitignore
deleted file mode 100644
index 4d4c7b1710b0..000000000000
diff --git a/libmlx4/configure.ac b/libmlx4/configure.ac
deleted file mode 100644
index 01bf7cbcf163..000000000000
diff --git a/libmlx4/mlx4.driver b/libmlx4/mlx4.driver
deleted file mode 100644
index 4d29fa818afe..000000000000
diff --git a/libmlx4/src/mlx4.map b/libmlx4/src/mlx4.map
deleted file mode 100644
index ae8ed861f956..000000000000
diff --git a/libmlx5/Makefile.am b/libmlx5/Makefile.am
deleted file mode 100644
index 345d5afbcfee..000000000000
diff --git a/libmlx5/autogen.sh b/libmlx5/autogen.sh
deleted file mode 100755
index b0ad85eb4cb9..000000000000
diff --git a/libmlx5/config/.gitignore b/libmlx5/config/.gitignore
deleted file mode 100644
index 4d4c7b1710b0..000000000000
diff --git a/libmlx5/configure.ac b/libmlx5/configure.ac
deleted file mode 100644
index cd235474245e..000000000000
diff --git a/libmlx5/m4/ax_gcc_func_attribute.m4 b/libmlx5/m4/ax_gcc_func_attribute.m4
deleted file mode 100644
index c788ca9bd435..000000000000
diff --git a/libmlx5/mlx5.driver b/libmlx5/mlx5.driver
deleted file mode 100644
index 5190aa59ab50..000000000000
diff --git a/libmlx5/src/mlx5.map b/libmlx5/src/mlx5.map
deleted file mode 100644
index ae8ed861f956..000000000000
diff --git a/libmthca/Makefile.am b/libmthca/Makefile.am
deleted file mode 100644
index 1dd9a7ba8601..000000000000
diff --git a/libmthca/autogen.sh b/libmthca/autogen.sh
deleted file mode 100755
index fd47839cae8c..000000000000
diff --git a/libmthca/config/.gitignore b/libmthca/config/.gitignore
deleted file mode 100644
index 4d4c7b1710b0..000000000000
diff --git a/libmthca/configure.in b/libmthca/configure.in
deleted file mode 100644
index fb665ed2dd40..000000000000
diff --git a/libmthca/mthca.driver b/libmthca/mthca.driver
deleted file mode 100644
index 5880a477f9c4..000000000000
diff --git a/libmthca/src/mthca.map b/libmthca/src/mthca.map
deleted file mode 100644
index ae8ed861f956..000000000000
diff --git a/libnes/Makefile.am b/libnes/Makefile.am
deleted file mode 100644
index ade8e8b1eee8..000000000000
diff --git a/libnes/autogen.sh b/libnes/autogen.sh
deleted file mode 100755
index 1e486f86b880..000000000000
diff --git a/libnes/config/.gitignore b/libnes/config/.gitignore
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/libnes/configure.in b/libnes/configure.in
deleted file mode 100644
index a25d129cc159..000000000000
diff --git a/libnes/nes.driver b/libnes/nes.driver
deleted file mode 100644
index 1d8d85d51758..000000000000
diff --git a/libnes/src/nes.map b/libnes/src/nes.map
deleted file mode 100644
index ae8ed861f956..000000000000
diff --git a/libocrdma/Makefile.am b/libocrdma/Makefile.am
deleted file mode 100644
index 9b786e2b51a4..000000000000
diff --git a/libocrdma/autogen.sh b/libocrdma/autogen.sh
deleted file mode 100644
index fd47839cae8c..000000000000
diff --git a/libocrdma/config/.gitignore b/libocrdma/config/.gitignore
deleted file mode 100644
index 4d4c7b1710b0..000000000000
diff --git a/libocrdma/configure.in b/libocrdma/configure.in
deleted file mode 100644
index 2fd54b5ecd72..000000000000
diff --git a/libocrdma/ocrdma.driver b/libocrdma/ocrdma.driver
deleted file mode 100644
index dead9f84707e..000000000000
diff --git a/libocrdma/src/ocrdma.map b/libocrdma/src/ocrdma.map
deleted file mode 100644
index ae8ed861f956..000000000000
diff --git a/librdmacm/Makefile.am b/librdmacm/Makefile.am
deleted file mode 100644
index edfb36bb4149..000000000000
diff --git a/librdmacm/autogen.sh b/librdmacm/autogen.sh
deleted file mode 100755
index 24c0a769be34..000000000000
diff --git a/librdmacm/configure.ac b/librdmacm/configure.ac
deleted file mode 100644
index 768e2573f754..000000000000
diff --git a/librxe/AUTHORS b/librxe/AUTHORS
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/librxe/COPYING b/librxe/COPYING
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/librxe/INSTALL b/librxe/INSTALL
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/librxe/Makefile.am b/librxe/Makefile.am
deleted file mode 100644
index 972ae3b390b7..000000000000
diff --git a/librxe/Makefile.in b/librxe/Makefile.in
deleted file mode 100644
index aa536082e9ef..000000000000
diff --git a/librxe/NEWS b/librxe/NEWS
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/librxe/README b/librxe/README
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/librxe/aclocal.m4 b/librxe/aclocal.m4
deleted file mode 100644
index 4ccc6e2225b5..000000000000
diff --git a/librxe/config.h.in b/librxe/config.h.in
deleted file mode 100644
index eda71c5b3524..000000000000
diff --git a/librxe/config/config.guess b/librxe/config/config.guess
deleted file mode 100755
index f32079abda66..000000000000
diff --git a/librxe/config/config.sub b/librxe/config/config.sub
deleted file mode 100755
index 6759825a5b7f..000000000000
diff --git a/librxe/config/depcomp b/librxe/config/depcomp
deleted file mode 100755
index 04701da536f3..000000000000
diff --git a/librxe/config/install-sh b/librxe/config/install-sh
deleted file mode 100755
index a5897de6ea7f..000000000000
diff --git a/librxe/config/ltmain.sh b/librxe/config/ltmain.sh
deleted file mode 100755
index 3061e3c5a2f7..000000000000
diff --git a/librxe/config/missing b/librxe/config/missing
deleted file mode 100755
index 894e786e16c1..000000000000
diff --git a/librxe/configure b/librxe/configure
deleted file mode 100755
index a2af18f879ef..000000000000
diff --git a/librxe/configure.in b/librxe/configure.in
deleted file mode 100644
index 8927cef50468..000000000000
diff --git a/librxe/librxe.spec b/librxe/librxe.spec
deleted file mode 100644
index 7f65163c1079..000000000000
diff --git a/librxe/rxe.driver b/librxe/rxe.driver
deleted file mode 100644
index ed63053225fd..000000000000
diff --git a/librxe/src/rxe.map b/librxe/src/rxe.map
deleted file mode 100644
index 710d82708fd1..000000000000
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* [RFCv2 11/15] Remove the ChangeLog files
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (9 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 10/15] Remove the auto* based build systems Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 12/15] Combine COPYING files Jason Gunthorpe
` (7 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
These are either empty, an old copy of 'git log' or some very
old logs.
New stuff uses git, the changelog is in git, no need to keep these.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
libcxgb3/ChangeLog | 791 -----------------------------------
libcxgb4/ChangeLog | 1133 --------------------------------------------------
libibcm/ChangeLog | 0
libibumad/ChangeLog | 94 -----
libibverbs/ChangeLog | 583 --------------------------
libmthca/ChangeLog | 378 -----------------
librdmacm/ChangeLog | 0
librxe/ChangeLog | 0
8 files changed, 2979 deletions(-)
delete mode 100644 libcxgb3/ChangeLog
delete mode 100644 libcxgb4/ChangeLog
delete mode 100644 libibcm/ChangeLog
delete mode 100644 libibumad/ChangeLog
delete mode 100644 libibverbs/ChangeLog
delete mode 100644 libmthca/ChangeLog
delete mode 100644 librdmacm/ChangeLog
delete mode 100644 librxe/ChangeLog
diff --git a/libcxgb3/ChangeLog b/libcxgb3/ChangeLog
deleted file mode 100644
index 6e3de6058a0f..000000000000
diff --git a/libcxgb4/ChangeLog b/libcxgb4/ChangeLog
deleted file mode 100644
index c472b6d49436..000000000000
diff --git a/libibcm/ChangeLog b/libibcm/ChangeLog
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/libibumad/ChangeLog b/libibumad/ChangeLog
deleted file mode 100644
index f394ef8c89a9..000000000000
diff --git a/libibverbs/ChangeLog b/libibverbs/ChangeLog
deleted file mode 100644
index 27ee956ddac8..000000000000
diff --git a/libmthca/ChangeLog b/libmthca/ChangeLog
deleted file mode 100644
index 015ed3881f05..000000000000
diff --git a/librdmacm/ChangeLog b/librdmacm/ChangeLog
deleted file mode 100644
index e69de29bb2d1..000000000000
diff --git a/librxe/ChangeLog b/librxe/ChangeLog
deleted file mode 100644
index e69de29bb2d1..000000000000
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* [RFCv2 12/15] Combine COPYING files
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (10 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 11/15] Remove the ChangeLog files Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 13/15] Consolidate the .gitignore files Jason Gunthorpe
` (6 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
Provide common reference files COPYING.BSD and COPYING.GPL2, as
well as a general 'default' in COPYING
The following directories retain their existing COPYING files because
they do not conform to the Open Fabrics standard:
- libcxgb3,libipathverbs,libnes contain an extra patent restriction
- libhfi1verbs uses Intel BSD 3 clause license not the OpenIB.org
2 clause license
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
COPYING | 6 +
COPYING.BSD | 26 +++
libnes/gpl-2.0.txt => COPYING.GPL2 | 14 +-
libcxgb4/COPYING | 29 ---
libi40iw/COPYING | 372 ------------------------------------
libibcm/COPYING | 378 -------------------------------------
libibumad/COPYING | 377 ------------------------------------
libibverbs/COPYING | 378 -------------------------------------
libmlx4/COPYING | 378 -------------------------------------
libmlx5/COPYING | 378 -------------------------------------
libmthca/COPYING | 378 -------------------------------------
libocrdma/COPYING | 317 -------------------------------
librdmacm/COPYING | 378 -------------------------------------
13 files changed, 39 insertions(+), 3370 deletions(-)
create mode 100644 COPYING
create mode 100644 COPYING.BSD
rename libnes/gpl-2.0.txt => COPYING.GPL2 (98%)
delete mode 100644 libcxgb4/COPYING
delete mode 100644 libi40iw/COPYING
delete mode 100644 libibcm/COPYING
delete mode 100644 libibumad/COPYING
delete mode 100644 libibverbs/COPYING
delete mode 100644 libmlx4/COPYING
delete mode 100644 libmlx5/COPYING
delete mode 100644 libmthca/COPYING
delete mode 100644 libocrdma/COPYING
delete mode 100644 librdmacm/COPYING
diff --git a/COPYING b/COPYING
new file mode 100644
index 000000000000..ac58180e900c
--- /dev/null
+++ b/COPYING
@@ -0,0 +1,6 @@
+Unless otherwise stated this software is available to you under a choice of
+one of two licenses. You may choose to be licensed under the terms of the the
+OpenIB.org BSD license (see COPYING.BSD) or the GNU General Public License
+(GPL) Version 2 (see COPYING.GPL2), both included in this package.
+
+Refer to individual files for information on the copyright holders.
diff --git a/COPYING.BSD b/COPYING.BSD
new file mode 100644
index 000000000000..59b3a397a13b
--- /dev/null
+++ b/COPYING.BSD
@@ -0,0 +1,26 @@
+ OpenIB.org BSD license
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+ * Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+
+ * Redistributions in binary form must reproduce the above
+ copyright notice, this list of conditions and the following
+ disclaimer in the documentation and/or other materials provided
+ with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
+ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
diff --git a/libnes/gpl-2.0.txt b/COPYING.GPL2
similarity index 98%
rename from libnes/gpl-2.0.txt
rename to COPYING.GPL2
index d511905c1647..d159169d1050 100644
--- a/libnes/gpl-2.0.txt
+++ b/COPYING.GPL2
@@ -1,12 +1,12 @@
- GNU GENERAL PUBLIC LICENSE
- Version 2, June 1991
+ GNU GENERAL PUBLIC LICENSE
+ Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
- Preamble
+ Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
@@ -56,7 +56,7 @@ patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
- GNU GENERAL PUBLIC LICENSE
+ GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
@@ -255,7 +255,7 @@ make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
- NO WARRANTY
+ NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
@@ -277,9 +277,9 @@ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
- END OF TERMS AND CONDITIONS
+ END OF TERMS AND CONDITIONS
- How to Apply These Terms to Your New Programs
+ How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
diff --git a/libcxgb4/COPYING b/libcxgb4/COPYING
deleted file mode 100644
index 93b666faf583..000000000000
diff --git a/libi40iw/COPYING b/libi40iw/COPYING
deleted file mode 100644
index b275c841fb59..000000000000
diff --git a/libibcm/COPYING b/libibcm/COPYING
deleted file mode 100644
index ee1a79ffabf6..000000000000
diff --git a/libibumad/COPYING b/libibumad/COPYING
deleted file mode 100644
index c7f06f69e99e..000000000000
diff --git a/libibverbs/COPYING b/libibverbs/COPYING
deleted file mode 100644
index ee1a79ffabf6..000000000000
diff --git a/libmlx4/COPYING b/libmlx4/COPYING
deleted file mode 100644
index add3d1990bc1..000000000000
diff --git a/libmlx5/COPYING b/libmlx5/COPYING
deleted file mode 100644
index add3d1990bc1..000000000000
diff --git a/libmthca/COPYING b/libmthca/COPYING
deleted file mode 100644
index ee1a79ffabf6..000000000000
diff --git a/libocrdma/COPYING b/libocrdma/COPYING
deleted file mode 100644
index 17073373403b..000000000000
diff --git a/librdmacm/COPYING b/librdmacm/COPYING
deleted file mode 100644
index 39f3831585f2..000000000000
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 13/15] Consolidate the .gitignore files
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (11 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 12/15] Combine COPYING files Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 14/15] Move providers into providers/ Jason Gunthorpe
` (5 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
Remove auto* stuff in the sub directories and replace it with one
copy of cmake stuff in the top level.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
.gitignore | 29 +++++++++++++++++++
libhfi1verbs/.gitignore | 18 ------------
libibverbs/.gitignore | 24 ----------------
libibverbs/examples/.gitignore | 10 -------
libibverbs/src/.gitignore | 3 --
libipathverbs/.gitignore | 22 ---------------
libmlx4/.gitignore | 17 -----------
libmlx4/src/.gitignore | 3 --
libmlx5/.gitignore | 33 ----------------------
libmlx5/src/.gitignore | 3 --
libmthca/.gitignore | 17 -----------
libmthca/src/.gitignore | 3 --
librdmacm/.gitignore | 64 ------------------------------------------
librdmacm/examples/.gitignore | 23 ---------------
librdmacm/src/.gitignore | 9 ------
15 files changed, 29 insertions(+), 249 deletions(-)
create mode 100644 .gitignore
delete mode 100644 libhfi1verbs/.gitignore
delete mode 100644 libibverbs/.gitignore
delete mode 100644 libibverbs/examples/.gitignore
delete mode 100644 libibverbs/src/.gitignore
delete mode 100644 libipathverbs/.gitignore
delete mode 100644 libmlx4/.gitignore
delete mode 100644 libmlx4/src/.gitignore
delete mode 100644 libmlx5/.gitignore
delete mode 100644 libmlx5/src/.gitignore
delete mode 100644 libmthca/.gitignore
delete mode 100644 libmthca/src/.gitignore
delete mode 100644 librdmacm/.gitignore
delete mode 100644 librdmacm/examples/.gitignore
delete mode 100644 librdmacm/src/.gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000000000000..65cf06d22efa
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,29 @@
+# CMake
+cmake_install.cmake
+CMakeFiles
+CMakeCache.txt
+lib*.a
+/bin/**
+/lib/**
+/include/**
+/.ninja*
+*.ninja
+Makefile
+
+# Tags
+TAGS
+.TAGS
+!TAGS/
+tags
+.tags
+!tags/
+gtags.files
+GTAGS
+GRTAGS
+GPATH
+
+# cscope
+cscope.files
+cscope.out
+cscope.in.out
+cscope.po.out
diff --git a/libhfi1verbs/.gitignore b/libhfi1verbs/.gitignore
deleted file mode 100644
index 1fd7e821926c..000000000000
diff --git a/libibverbs/.gitignore b/libibverbs/.gitignore
deleted file mode 100644
index 9fb29eae8cd4..000000000000
diff --git a/libibverbs/examples/.gitignore b/libibverbs/examples/.gitignore
deleted file mode 100644
index ebecbdc0cf56..000000000000
diff --git a/libibverbs/src/.gitignore b/libibverbs/src/.gitignore
deleted file mode 100644
index 7297cbb20ade..000000000000
diff --git a/libipathverbs/.gitignore b/libipathverbs/.gitignore
deleted file mode 100644
index 007a003f6e53..000000000000
diff --git a/libmlx4/.gitignore b/libmlx4/.gitignore
deleted file mode 100644
index 4c45b0912563..000000000000
diff --git a/libmlx4/src/.gitignore b/libmlx4/src/.gitignore
deleted file mode 100644
index 7297cbb20ade..000000000000
diff --git a/libmlx5/.gitignore b/libmlx5/.gitignore
deleted file mode 100644
index 7878db2d068e..000000000000
diff --git a/libmlx5/src/.gitignore b/libmlx5/src/.gitignore
deleted file mode 100644
index 7297cbb20ade..000000000000
diff --git a/libmthca/.gitignore b/libmthca/.gitignore
deleted file mode 100644
index 43f0908f1de0..000000000000
diff --git a/libmthca/src/.gitignore b/libmthca/src/.gitignore
deleted file mode 100644
index 7297cbb20ade..000000000000
diff --git a/librdmacm/.gitignore b/librdmacm/.gitignore
deleted file mode 100644
index cea1f714f199..000000000000
diff --git a/librdmacm/examples/.gitignore b/librdmacm/examples/.gitignore
deleted file mode 100644
index ce9156d4a97f..000000000000
diff --git a/librdmacm/src/.gitignore b/librdmacm/src/.gitignore
deleted file mode 100644
index 139417a24de1..000000000000
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 14/15] Move providers into providers/
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (12 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 13/15] Consolidate the .gitignore files Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 15/15] Add a MAINTAINERS file Jason Gunthorpe
` (4 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
Also
- Delete debian and RPM packaging from providers
- Flatten the src/ directory into the root
- Drop the 'lib' prefix. These are plugins, not true libraries
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
CMakeLists.txt | 26 +++--
libcxgb3/libcxgb3.spec.in | 55 ----------
libcxgb4/libcxgb4.spec.in | 55 ----------
libhfi1verbs/libhfi1verbs.spec.in | 111 ---------------------
libi40iw/libi40iw.spec.in | 72 -------------
libipathverbs/libipathverbs.spec.in | 104 -------------------
libipathverbs/src/CMakeLists.txt | 4 -
libmlx4/debian/changelog | 73 --------------
libmlx4/debian/compat | 1 -
libmlx4/debian/control | 47 ---------
libmlx4/debian/copyright | 43 --------
libmlx4/debian/libmlx4-1.install | 2 -
libmlx4/debian/libmlx4-dev.install | 1 -
.../debian/patches/driver-plugin-directory.patch | 10 --
libmlx4/debian/patches/series | 1 -
libmlx4/debian/rules | 10 --
libmlx4/debian/source/format | 1 -
libmlx4/debian/watch | 3 -
libmlx4/libmlx4.spec.in | 90 -----------------
libmlx5/debian/changelog | 18 ----
libmlx5/debian/compat | 1 -
libmlx5/debian/control | 47 ---------
libmlx5/debian/copyright | 43 --------
libmlx5/debian/libmlx5-1.install | 2 -
libmlx5/debian/libmlx5-dev.install | 1 -
.../debian/patches/driver-plugin-directory.patch | 10 --
libmlx5/debian/patches/series | 1 -
libmlx5/debian/rules | 10 --
libmlx5/debian/source/format | 1 -
libmlx5/debian/watch | 3 -
libmlx5/libmlx5.spec.in | 60 -----------
libmthca/debian/changelog | 73 --------------
libmthca/debian/compat | 1 -
libmthca/debian/control | 48 ---------
libmthca/debian/copyright | 44 --------
libmthca/debian/libmthca-dev.install | 1 -
libmthca/debian/libmthca1.install | 2 -
.../debian/patches/driver-plugin-directory.patch | 10 --
libmthca/debian/patches/series | 1 -
libmthca/debian/rules | 10 --
libmthca/debian/source/format | 1 -
libmthca/debian/watch | 3 -
libmthca/libmthca.spec.in | 97 ------------------
libnes/libnes.spec.in | 107 --------------------
libocrdma/libocrdma.spec.in | 71 -------------
librxe/librxe.spec.in | 55 ----------
librxe/src/CMakeLists.txt | 3 -
{libcxgb4 => providers/cxgb3}/AUTHORS | 0
{libcxgb3/src => providers/cxgb3}/CMakeLists.txt | 0
{libcxgb3 => providers/cxgb3}/COPYING | 0
{libcxgb3 => providers/cxgb3}/README | 0
{libcxgb3/src => providers/cxgb3}/cq.c | 0
{libcxgb3/src => providers/cxgb3}/cxio_wr.h | 0
.../src => providers/cxgb3}/firmware_exports.h | 0
{libcxgb3/src => providers/cxgb3}/iwch-abi.h | 0
{libcxgb3/src => providers/cxgb3}/iwch.c | 0
{libcxgb3/src => providers/cxgb3}/iwch.h | 0
{libcxgb3/src => providers/cxgb3}/qp.c | 0
{libcxgb3/src => providers/cxgb3}/verbs.c | 0
{libcxgb3 => providers/cxgb4}/AUTHORS | 0
{libcxgb4/src => providers/cxgb4}/CMakeLists.txt | 0
{libcxgb4 => providers/cxgb4}/README | 0
{libcxgb4/src => providers/cxgb4}/cq.c | 0
{libcxgb4/src => providers/cxgb4}/cxgb4-abi.h | 0
{libcxgb4/src => providers/cxgb4}/dev.c | 0
{libcxgb4/src => providers/cxgb4}/libcxgb4.h | 0
{libcxgb4/src => providers/cxgb4}/qp.c | 0
{libcxgb4/src => providers/cxgb4}/queue.h | 0
{libcxgb4/src => providers/cxgb4}/t4.h | 0
{libcxgb4/src => providers/cxgb4}/t4_chip_type.h | 0
{libcxgb4/src => providers/cxgb4}/t4_pci_id_tbl.h | 0
{libcxgb4/src => providers/cxgb4}/t4_regs.h | 0
{libcxgb4/src => providers/cxgb4}/t4fw_interface.h | 0
{libcxgb4/src => providers/cxgb4}/verbs.c | 0
{libhfi1verbs => providers/hfi1verbs}/AUTHORS | 0
.../src => providers/hfi1verbs}/CMakeLists.txt | 0
{libhfi1verbs => providers/hfi1verbs}/COPYING | 0
{libhfi1verbs => providers/hfi1verbs}/README | 0
.../src => providers/hfi1verbs}/hfi-abi.h | 0
.../src => providers/hfi1verbs}/hfiverbs.c | 0
.../src => providers/hfi1verbs}/hfiverbs.h | 0
{libhfi1verbs/src => providers/hfi1verbs}/verbs.c | 0
{libnes => providers/i40iw}/AUTHORS | 0
{libi40iw/src => providers/i40iw}/CMakeLists.txt | 0
{libi40iw/src => providers/i40iw}/i40e_devids.h | 0
{libi40iw/src => providers/i40iw}/i40iw-abi.h | 0
{libi40iw/src => providers/i40iw}/i40iw_d.h | 0
{libi40iw/src => providers/i40iw}/i40iw_osdep.h | 0
{libi40iw/src => providers/i40iw}/i40iw_register.h | 0
{libi40iw/src => providers/i40iw}/i40iw_status.h | 0
{libi40iw/src => providers/i40iw}/i40iw_uk.c | 0
{libi40iw/src => providers/i40iw}/i40iw_umain.c | 0
{libi40iw/src => providers/i40iw}/i40iw_umain.h | 0
{libi40iw/src => providers/i40iw}/i40iw_user.h | 0
{libi40iw/src => providers/i40iw}/i40iw_uverbs.c | 0
{libipathverbs => providers/ipathverbs}/AUTHORS | 0
.../ipathverbs}/CMakeLists.txt | 4 +
{libipathverbs => providers/ipathverbs}/COPYING | 0
{libipathverbs => providers/ipathverbs}/README | 0
.../ipathverbs}/dracut_check | 0
.../ipathverbs}/dracut_install | 0
.../ipathverbs}/dracut_kmod | 0
.../src => providers/ipathverbs}/ipath-abi.h | 0
.../src => providers/ipathverbs}/ipathverbs.c | 0
.../src => providers/ipathverbs}/ipathverbs.h | 0
.../ipathverbs}/truescale-serdes.cmds | 0
.../ipathverbs}/truescale.conf | 0
.../src => providers/ipathverbs}/verbs.c | 0
{libmlx4 => providers/mlx4}/AUTHORS | 0
{libmlx4/src => providers/mlx4}/CMakeLists.txt | 0
{libmlx4 => providers/mlx4}/README | 0
{libmlx4/src => providers/mlx4}/buf.c | 0
{libmlx4/src => providers/mlx4}/cq.c | 0
{libmlx4/src => providers/mlx4}/dbrec.c | 0
{libmlx4/src => providers/mlx4}/doorbell.h | 0
{libmlx4/src => providers/mlx4}/mlx4-abi.h | 0
{libmlx4/src => providers/mlx4}/mlx4.c | 0
{libmlx4/src => providers/mlx4}/mlx4.h | 0
{libmlx4/src => providers/mlx4}/mmio.h | 0
{libmlx4/src => providers/mlx4}/qp.c | 0
{libmlx4/src => providers/mlx4}/srq.c | 0
{libmlx4/src => providers/mlx4}/verbs.c | 0
{libmlx4/src => providers/mlx4}/wqe.h | 0
{libmlx5 => providers/mlx5}/AUTHORS | 0
{libmlx5/src => providers/mlx5}/CMakeLists.txt | 0
{libmlx5 => providers/mlx5}/README | 0
{libmlx5/src => providers/mlx5}/bitmap.h | 0
{libmlx5/src => providers/mlx5}/buf.c | 0
{libmlx5/src => providers/mlx5}/cq.c | 0
{libmlx5/src => providers/mlx5}/dbrec.c | 0
{libmlx5/src => providers/mlx5}/doorbell.h | 0
{libmlx5/src => providers/mlx5}/list.h | 0
{libmlx5/src => providers/mlx5}/mlx5-abi.h | 0
{libmlx5/src => providers/mlx5}/mlx5.c | 0
{libmlx5/src => providers/mlx5}/mlx5.h | 0
{libmlx5/src => providers/mlx5}/qp.c | 0
{libmlx5/src => providers/mlx5}/srq.c | 0
{libmlx5/src => providers/mlx5}/verbs.c | 0
{libmlx5/src => providers/mlx5}/wqe.h | 0
{libmthca => providers/mthca}/AUTHORS | 0
{libmthca/src => providers/mthca}/CMakeLists.txt | 0
{libmthca => providers/mthca}/README | 0
{libmthca/src => providers/mthca}/ah.c | 0
{libmthca/src => providers/mthca}/buf.c | 0
{libmthca/src => providers/mthca}/cq.c | 0
{libmthca/src => providers/mthca}/doorbell.h | 0
{libmthca/src => providers/mthca}/memfree.c | 0
{libmthca/src => providers/mthca}/mthca-abi.h | 0
{libmthca/src => providers/mthca}/mthca.c | 0
{libmthca/src => providers/mthca}/mthca.h | 0
{libmthca/src => providers/mthca}/qp.c | 0
{libmthca/src => providers/mthca}/srq.c | 0
{libmthca/src => providers/mthca}/verbs.c | 0
{libmthca/src => providers/mthca}/wqe.h | 0
{libi40iw => providers/nes}/AUTHORS | 0
{libnes/src => providers/nes}/CMakeLists.txt | 0
{libnes => providers/nes}/COPYING | 0
{libnes/src => providers/nes}/nes-abi.h | 0
{libnes/src => providers/nes}/nes_umain.c | 0
{libnes/src => providers/nes}/nes_umain.h | 0
{libnes/src => providers/nes}/nes_uverbs.c | 0
{libocrdma => providers/ocrdma}/AUTHORS | 0
{libocrdma/src => providers/ocrdma}/CMakeLists.txt | 0
{libocrdma => providers/ocrdma}/Changelog | 0
{libocrdma => providers/ocrdma}/README | 0
{libocrdma/src => providers/ocrdma}/ocrdma_abi.h | 0
{libocrdma/src => providers/ocrdma}/ocrdma_list.h | 0
{libocrdma/src => providers/ocrdma}/ocrdma_main.c | 0
{libocrdma/src => providers/ocrdma}/ocrdma_main.h | 0
{libocrdma/src => providers/ocrdma}/ocrdma_verbs.c | 0
{librxe => providers/rxe}/CMakeLists.txt | 3 +
{librxe => providers/rxe}/README.md | 0
{librxe => providers/rxe}/man/CMakeLists.txt | 0
{librxe => providers/rxe}/man/rxe.7 | 0
{librxe => providers/rxe}/man/rxe_cfg.8 | 0
{librxe/src => providers/rxe}/rxe-abi.h | 0
{librxe/src => providers/rxe}/rxe.c | 0
{librxe/src => providers/rxe}/rxe.h | 0
{librxe => providers/rxe}/rxe_cfg | 0
{librxe/src => providers/rxe}/rxe_queue.h | 0
180 files changed, 19 insertions(+), 1421 deletions(-)
delete mode 100644 libcxgb3/libcxgb3.spec.in
delete mode 100644 libcxgb4/libcxgb4.spec.in
delete mode 100644 libhfi1verbs/libhfi1verbs.spec.in
delete mode 100644 libi40iw/libi40iw.spec.in
delete mode 100644 libipathverbs/libipathverbs.spec.in
delete mode 100644 libipathverbs/src/CMakeLists.txt
delete mode 100644 libmlx4/debian/changelog
delete mode 100644 libmlx4/debian/compat
delete mode 100644 libmlx4/debian/control
delete mode 100644 libmlx4/debian/copyright
delete mode 100644 libmlx4/debian/libmlx4-1.install
delete mode 100644 libmlx4/debian/libmlx4-dev.install
delete mode 100644 libmlx4/debian/patches/driver-plugin-directory.patch
delete mode 100644 libmlx4/debian/patches/series
delete mode 100755 libmlx4/debian/rules
delete mode 100644 libmlx4/debian/source/format
delete mode 100644 libmlx4/debian/watch
delete mode 100644 libmlx4/libmlx4.spec.in
delete mode 100644 libmlx5/debian/changelog
delete mode 100644 libmlx5/debian/compat
delete mode 100644 libmlx5/debian/control
delete mode 100644 libmlx5/debian/copyright
delete mode 100644 libmlx5/debian/libmlx5-1.install
delete mode 100644 libmlx5/debian/libmlx5-dev.install
delete mode 100644 libmlx5/debian/patches/driver-plugin-directory.patch
delete mode 100644 libmlx5/debian/patches/series
delete mode 100755 libmlx5/debian/rules
delete mode 100644 libmlx5/debian/source/format
delete mode 100644 libmlx5/debian/watch
delete mode 100644 libmlx5/libmlx5.spec.in
delete mode 100644 libmthca/debian/changelog
delete mode 100644 libmthca/debian/compat
delete mode 100644 libmthca/debian/control
delete mode 100644 libmthca/debian/copyright
delete mode 100644 libmthca/debian/libmthca-dev.install
delete mode 100644 libmthca/debian/libmthca1.install
delete mode 100644 libmthca/debian/patches/driver-plugin-directory.patch
delete mode 100644 libmthca/debian/patches/series
delete mode 100755 libmthca/debian/rules
delete mode 100644 libmthca/debian/source/format
delete mode 100644 libmthca/debian/watch
delete mode 100644 libmthca/libmthca.spec.in
delete mode 100644 libnes/libnes.spec.in
delete mode 100644 libocrdma/libocrdma.spec.in
delete mode 100644 librxe/librxe.spec.in
delete mode 100644 librxe/src/CMakeLists.txt
rename {libcxgb4 => providers/cxgb3}/AUTHORS (100%)
rename {libcxgb3/src => providers/cxgb3}/CMakeLists.txt (100%)
rename {libcxgb3 => providers/cxgb3}/COPYING (100%)
rename {libcxgb3 => providers/cxgb3}/README (100%)
rename {libcxgb3/src => providers/cxgb3}/cq.c (100%)
rename {libcxgb3/src => providers/cxgb3}/cxio_wr.h (100%)
rename {libcxgb3/src => providers/cxgb3}/firmware_exports.h (100%)
rename {libcxgb3/src => providers/cxgb3}/iwch-abi.h (100%)
rename {libcxgb3/src => providers/cxgb3}/iwch.c (100%)
rename {libcxgb3/src => providers/cxgb3}/iwch.h (100%)
rename {libcxgb3/src => providers/cxgb3}/qp.c (100%)
rename {libcxgb3/src => providers/cxgb3}/verbs.c (100%)
rename {libcxgb3 => providers/cxgb4}/AUTHORS (100%)
rename {libcxgb4/src => providers/cxgb4}/CMakeLists.txt (100%)
rename {libcxgb4 => providers/cxgb4}/README (100%)
rename {libcxgb4/src => providers/cxgb4}/cq.c (100%)
rename {libcxgb4/src => providers/cxgb4}/cxgb4-abi.h (100%)
rename {libcxgb4/src => providers/cxgb4}/dev.c (100%)
rename {libcxgb4/src => providers/cxgb4}/libcxgb4.h (100%)
rename {libcxgb4/src => providers/cxgb4}/qp.c (100%)
rename {libcxgb4/src => providers/cxgb4}/queue.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4_chip_type.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4_pci_id_tbl.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4_regs.h (100%)
rename {libcxgb4/src => providers/cxgb4}/t4fw_interface.h (100%)
rename {libcxgb4/src => providers/cxgb4}/verbs.c (100%)
rename {libhfi1verbs => providers/hfi1verbs}/AUTHORS (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/CMakeLists.txt (100%)
rename {libhfi1verbs => providers/hfi1verbs}/COPYING (100%)
rename {libhfi1verbs => providers/hfi1verbs}/README (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/hfi-abi.h (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/hfiverbs.c (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/hfiverbs.h (100%)
rename {libhfi1verbs/src => providers/hfi1verbs}/verbs.c (100%)
rename {libnes => providers/i40iw}/AUTHORS (100%)
rename {libi40iw/src => providers/i40iw}/CMakeLists.txt (100%)
rename {libi40iw/src => providers/i40iw}/i40e_devids.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw-abi.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_d.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_osdep.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_register.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_status.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_uk.c (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_umain.c (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_umain.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_user.h (100%)
rename {libi40iw/src => providers/i40iw}/i40iw_uverbs.c (100%)
rename {libipathverbs => providers/ipathverbs}/AUTHORS (100%)
rename {libipathverbs => providers/ipathverbs}/CMakeLists.txt (80%)
rename {libipathverbs => providers/ipathverbs}/COPYING (100%)
rename {libipathverbs => providers/ipathverbs}/README (100%)
rename {libipathverbs => providers/ipathverbs}/dracut_check (100%)
rename {libipathverbs => providers/ipathverbs}/dracut_install (100%)
rename {libipathverbs => providers/ipathverbs}/dracut_kmod (100%)
rename {libipathverbs/src => providers/ipathverbs}/ipath-abi.h (100%)
rename {libipathverbs/src => providers/ipathverbs}/ipathverbs.c (100%)
rename {libipathverbs/src => providers/ipathverbs}/ipathverbs.h (100%)
rename {libipathverbs => providers/ipathverbs}/truescale-serdes.cmds (100%)
rename {libipathverbs => providers/ipathverbs}/truescale.conf (100%)
rename {libipathverbs/src => providers/ipathverbs}/verbs.c (100%)
rename {libmlx4 => providers/mlx4}/AUTHORS (100%)
rename {libmlx4/src => providers/mlx4}/CMakeLists.txt (100%)
rename {libmlx4 => providers/mlx4}/README (100%)
rename {libmlx4/src => providers/mlx4}/buf.c (100%)
rename {libmlx4/src => providers/mlx4}/cq.c (100%)
rename {libmlx4/src => providers/mlx4}/dbrec.c (100%)
rename {libmlx4/src => providers/mlx4}/doorbell.h (100%)
rename {libmlx4/src => providers/mlx4}/mlx4-abi.h (100%)
rename {libmlx4/src => providers/mlx4}/mlx4.c (100%)
rename {libmlx4/src => providers/mlx4}/mlx4.h (100%)
rename {libmlx4/src => providers/mlx4}/mmio.h (100%)
rename {libmlx4/src => providers/mlx4}/qp.c (100%)
rename {libmlx4/src => providers/mlx4}/srq.c (100%)
rename {libmlx4/src => providers/mlx4}/verbs.c (100%)
rename {libmlx4/src => providers/mlx4}/wqe.h (100%)
rename {libmlx5 => providers/mlx5}/AUTHORS (100%)
rename {libmlx5/src => providers/mlx5}/CMakeLists.txt (100%)
rename {libmlx5 => providers/mlx5}/README (100%)
rename {libmlx5/src => providers/mlx5}/bitmap.h (100%)
rename {libmlx5/src => providers/mlx5}/buf.c (100%)
rename {libmlx5/src => providers/mlx5}/cq.c (100%)
rename {libmlx5/src => providers/mlx5}/dbrec.c (100%)
rename {libmlx5/src => providers/mlx5}/doorbell.h (100%)
rename {libmlx5/src => providers/mlx5}/list.h (100%)
rename {libmlx5/src => providers/mlx5}/mlx5-abi.h (100%)
rename {libmlx5/src => providers/mlx5}/mlx5.c (100%)
rename {libmlx5/src => providers/mlx5}/mlx5.h (100%)
rename {libmlx5/src => providers/mlx5}/qp.c (100%)
rename {libmlx5/src => providers/mlx5}/srq.c (100%)
rename {libmlx5/src => providers/mlx5}/verbs.c (100%)
rename {libmlx5/src => providers/mlx5}/wqe.h (100%)
rename {libmthca => providers/mthca}/AUTHORS (100%)
rename {libmthca/src => providers/mthca}/CMakeLists.txt (100%)
rename {libmthca => providers/mthca}/README (100%)
rename {libmthca/src => providers/mthca}/ah.c (100%)
rename {libmthca/src => providers/mthca}/buf.c (100%)
rename {libmthca/src => providers/mthca}/cq.c (100%)
rename {libmthca/src => providers/mthca}/doorbell.h (100%)
rename {libmthca/src => providers/mthca}/memfree.c (100%)
rename {libmthca/src => providers/mthca}/mthca-abi.h (100%)
rename {libmthca/src => providers/mthca}/mthca.c (100%)
rename {libmthca/src => providers/mthca}/mthca.h (100%)
rename {libmthca/src => providers/mthca}/qp.c (100%)
rename {libmthca/src => providers/mthca}/srq.c (100%)
rename {libmthca/src => providers/mthca}/verbs.c (100%)
rename {libmthca/src => providers/mthca}/wqe.h (100%)
rename {libi40iw => providers/nes}/AUTHORS (100%)
rename {libnes/src => providers/nes}/CMakeLists.txt (100%)
rename {libnes => providers/nes}/COPYING (100%)
rename {libnes/src => providers/nes}/nes-abi.h (100%)
rename {libnes/src => providers/nes}/nes_umain.c (100%)
rename {libnes/src => providers/nes}/nes_umain.h (100%)
rename {libnes/src => providers/nes}/nes_uverbs.c (100%)
rename {libocrdma => providers/ocrdma}/AUTHORS (100%)
rename {libocrdma/src => providers/ocrdma}/CMakeLists.txt (100%)
rename {libocrdma => providers/ocrdma}/Changelog (100%)
rename {libocrdma => providers/ocrdma}/README (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_abi.h (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_list.h (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_main.c (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_main.h (100%)
rename {libocrdma/src => providers/ocrdma}/ocrdma_verbs.c (100%)
rename {librxe => providers/rxe}/CMakeLists.txt (82%)
rename {librxe => providers/rxe}/README.md (100%)
rename {librxe => providers/rxe}/man/CMakeLists.txt (100%)
rename {librxe => providers/rxe}/man/rxe.7 (100%)
rename {librxe => providers/rxe}/man/rxe_cfg.8 (100%)
rename {librxe/src => providers/rxe}/rxe-abi.h (100%)
rename {librxe/src => providers/rxe}/rxe.c (100%)
rename {librxe/src => providers/rxe}/rxe.h (100%)
rename {librxe => providers/rxe}/rxe_cfg (100%)
rename {librxe/src => providers/rxe}/rxe_queue.h (100%)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 4058c8a68258..f18e65289396 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -188,20 +188,18 @@ add_subdirectory(librdmacm/man)
add_subdirectory(libibcm/src)
# Providers
-add_subdirectory(libcxgb3/src)
-add_subdirectory(libcxgb4/src)
-add_subdirectory(libhfi1verbs/src)
-add_subdirectory(libi40iw/src)
-add_subdirectory(libipathverbs/src)
-add_subdirectory(libipathverbs/)
-add_subdirectory(libmlx4/src)
-add_subdirectory(libmlx5/src)
-add_subdirectory(libmthca/src)
-add_subdirectory(libnes/src)
-add_subdirectory(libocrdma/src)
-add_subdirectory(librxe/src)
-add_subdirectory(librxe/man)
-add_subdirectory(librxe/)
+add_subdirectory(providers/cxgb3)
+add_subdirectory(providers/cxgb4)
+add_subdirectory(providers/hfi1verbs)
+add_subdirectory(providers/i40iw)
+add_subdirectory(providers/ipathverbs)
+add_subdirectory(providers/mlx4)
+add_subdirectory(providers/mlx5)
+add_subdirectory(providers/mthca)
+add_subdirectory(providers/nes)
+add_subdirectory(providers/ocrdma)
+add_subdirectory(providers/rxe)
+add_subdirectory(providers/rxe/man)
# Binaries
add_subdirectory(libibcm/examples)
diff --git a/libcxgb3/libcxgb3.spec.in b/libcxgb3/libcxgb3.spec.in
deleted file mode 100644
index 1ae72d793111..000000000000
diff --git a/libcxgb4/libcxgb4.spec.in b/libcxgb4/libcxgb4.spec.in
deleted file mode 100644
index 6b4294468cf0..000000000000
diff --git a/libhfi1verbs/libhfi1verbs.spec.in b/libhfi1verbs/libhfi1verbs.spec.in
deleted file mode 100644
index 110d795cc31b..000000000000
diff --git a/libi40iw/libi40iw.spec.in b/libi40iw/libi40iw.spec.in
deleted file mode 100644
index 4e794fa1898c..000000000000
diff --git a/libipathverbs/libipathverbs.spec.in b/libipathverbs/libipathverbs.spec.in
deleted file mode 100644
index d029696d70ef..000000000000
diff --git a/libipathverbs/src/CMakeLists.txt b/libipathverbs/src/CMakeLists.txt
deleted file mode 100644
index 20924fda7900..000000000000
diff --git a/libmlx4/debian/changelog b/libmlx4/debian/changelog
deleted file mode 100644
index ec7ba21e0573..000000000000
diff --git a/libmlx4/debian/compat b/libmlx4/debian/compat
deleted file mode 100644
index 7f8f011eb73d..000000000000
diff --git a/libmlx4/debian/control b/libmlx4/debian/control
deleted file mode 100644
index ab08e00e4eeb..000000000000
diff --git a/libmlx4/debian/copyright b/libmlx4/debian/copyright
deleted file mode 100644
index db07a25fcbf1..000000000000
diff --git a/libmlx4/debian/libmlx4-1.install b/libmlx4/debian/libmlx4-1.install
deleted file mode 100644
index 8cab406b098d..000000000000
diff --git a/libmlx4/debian/libmlx4-dev.install b/libmlx4/debian/libmlx4-dev.install
deleted file mode 100644
index 8f70e5214388..000000000000
diff --git a/libmlx4/debian/patches/driver-plugin-directory.patch b/libmlx4/debian/patches/driver-plugin-directory.patch
deleted file mode 100644
index fd73a739f424..000000000000
diff --git a/libmlx4/debian/patches/series b/libmlx4/debian/patches/series
deleted file mode 100644
index 213f49e4c278..000000000000
diff --git a/libmlx4/debian/rules b/libmlx4/debian/rules
deleted file mode 100755
index 9d15bec7c2a8..000000000000
diff --git a/libmlx4/debian/source/format b/libmlx4/debian/source/format
deleted file mode 100644
index 163aaf8d82b6..000000000000
diff --git a/libmlx4/debian/watch b/libmlx4/debian/watch
deleted file mode 100644
index 06bae51d7eb3..000000000000
diff --git a/libmlx4/libmlx4.spec.in b/libmlx4/libmlx4.spec.in
deleted file mode 100644
index 3c93122b5a02..000000000000
diff --git a/libmlx5/debian/changelog b/libmlx5/debian/changelog
deleted file mode 100644
index f43b43f41dfd..000000000000
diff --git a/libmlx5/debian/compat b/libmlx5/debian/compat
deleted file mode 100644
index 7f8f011eb73d..000000000000
diff --git a/libmlx5/debian/control b/libmlx5/debian/control
deleted file mode 100644
index 0aceae4a25ae..000000000000
diff --git a/libmlx5/debian/copyright b/libmlx5/debian/copyright
deleted file mode 100644
index db07a25fcbf1..000000000000
diff --git a/libmlx5/debian/libmlx5-1.install b/libmlx5/debian/libmlx5-1.install
deleted file mode 100644
index 1af89543be5a..000000000000
diff --git a/libmlx5/debian/libmlx5-dev.install b/libmlx5/debian/libmlx5-dev.install
deleted file mode 100644
index 7de9fbe4978b..000000000000
diff --git a/libmlx5/debian/patches/driver-plugin-directory.patch b/libmlx5/debian/patches/driver-plugin-directory.patch
deleted file mode 100644
index 91eb0482b3bb..000000000000
diff --git a/libmlx5/debian/patches/series b/libmlx5/debian/patches/series
deleted file mode 100644
index 213f49e4c278..000000000000
diff --git a/libmlx5/debian/rules b/libmlx5/debian/rules
deleted file mode 100755
index c8a46746512a..000000000000
diff --git a/libmlx5/debian/source/format b/libmlx5/debian/source/format
deleted file mode 100644
index 163aaf8d82b6..000000000000
diff --git a/libmlx5/debian/watch b/libmlx5/debian/watch
deleted file mode 100644
index cf13e694b2f8..000000000000
diff --git a/libmlx5/libmlx5.spec.in b/libmlx5/libmlx5.spec.in
deleted file mode 100644
index 8c73c40fea39..000000000000
diff --git a/libmthca/debian/changelog b/libmthca/debian/changelog
deleted file mode 100644
index d106ed76b49a..000000000000
diff --git a/libmthca/debian/compat b/libmthca/debian/compat
deleted file mode 100644
index 7f8f011eb73d..000000000000
diff --git a/libmthca/debian/control b/libmthca/debian/control
deleted file mode 100644
index 5ad14106b85c..000000000000
diff --git a/libmthca/debian/copyright b/libmthca/debian/copyright
deleted file mode 100644
index 04abee0b74f7..000000000000
diff --git a/libmthca/debian/libmthca-dev.install b/libmthca/debian/libmthca-dev.install
deleted file mode 100644
index e8122b99f572..000000000000
diff --git a/libmthca/debian/libmthca1.install b/libmthca/debian/libmthca1.install
deleted file mode 100644
index 7d1d899e896f..000000000000
diff --git a/libmthca/debian/patches/driver-plugin-directory.patch b/libmthca/debian/patches/driver-plugin-directory.patch
deleted file mode 100644
index 2ed7a66a24c0..000000000000
diff --git a/libmthca/debian/patches/series b/libmthca/debian/patches/series
deleted file mode 100644
index 213f49e4c278..000000000000
diff --git a/libmthca/debian/rules b/libmthca/debian/rules
deleted file mode 100755
index 902923802e67..000000000000
diff --git a/libmthca/debian/source/format b/libmthca/debian/source/format
deleted file mode 100644
index 163aaf8d82b6..000000000000
diff --git a/libmthca/debian/watch b/libmthca/debian/watch
deleted file mode 100644
index 8010f867b5d5..000000000000
diff --git a/libmthca/libmthca.spec.in b/libmthca/libmthca.spec.in
deleted file mode 100644
index f23a159a5b97..000000000000
diff --git a/libnes/libnes.spec.in b/libnes/libnes.spec.in
deleted file mode 100644
index 251365aedd1d..000000000000
diff --git a/libocrdma/libocrdma.spec.in b/libocrdma/libocrdma.spec.in
deleted file mode 100644
index 5f7d9f13c527..000000000000
diff --git a/librxe/librxe.spec.in b/librxe/librxe.spec.in
deleted file mode 100644
index 16dbaa615946..000000000000
diff --git a/librxe/src/CMakeLists.txt b/librxe/src/CMakeLists.txt
deleted file mode 100644
index d8f3265176e4..000000000000
diff --git a/libcxgb4/AUTHORS b/providers/cxgb3/AUTHORS
similarity index 100%
rename from libcxgb4/AUTHORS
rename to providers/cxgb3/AUTHORS
diff --git a/libcxgb3/src/CMakeLists.txt b/providers/cxgb3/CMakeLists.txt
similarity index 100%
rename from libcxgb3/src/CMakeLists.txt
rename to providers/cxgb3/CMakeLists.txt
diff --git a/libcxgb3/COPYING b/providers/cxgb3/COPYING
similarity index 100%
rename from libcxgb3/COPYING
rename to providers/cxgb3/COPYING
diff --git a/libcxgb3/README b/providers/cxgb3/README
similarity index 100%
rename from libcxgb3/README
rename to providers/cxgb3/README
diff --git a/libcxgb3/src/cq.c b/providers/cxgb3/cq.c
similarity index 100%
rename from libcxgb3/src/cq.c
rename to providers/cxgb3/cq.c
diff --git a/libcxgb3/src/cxio_wr.h b/providers/cxgb3/cxio_wr.h
similarity index 100%
rename from libcxgb3/src/cxio_wr.h
rename to providers/cxgb3/cxio_wr.h
diff --git a/libcxgb3/src/firmware_exports.h b/providers/cxgb3/firmware_exports.h
similarity index 100%
rename from libcxgb3/src/firmware_exports.h
rename to providers/cxgb3/firmware_exports.h
diff --git a/libcxgb3/src/iwch-abi.h b/providers/cxgb3/iwch-abi.h
similarity index 100%
rename from libcxgb3/src/iwch-abi.h
rename to providers/cxgb3/iwch-abi.h
diff --git a/libcxgb3/src/iwch.c b/providers/cxgb3/iwch.c
similarity index 100%
rename from libcxgb3/src/iwch.c
rename to providers/cxgb3/iwch.c
diff --git a/libcxgb3/src/iwch.h b/providers/cxgb3/iwch.h
similarity index 100%
rename from libcxgb3/src/iwch.h
rename to providers/cxgb3/iwch.h
diff --git a/libcxgb3/src/qp.c b/providers/cxgb3/qp.c
similarity index 100%
rename from libcxgb3/src/qp.c
rename to providers/cxgb3/qp.c
diff --git a/libcxgb3/src/verbs.c b/providers/cxgb3/verbs.c
similarity index 100%
rename from libcxgb3/src/verbs.c
rename to providers/cxgb3/verbs.c
diff --git a/libcxgb3/AUTHORS b/providers/cxgb4/AUTHORS
similarity index 100%
rename from libcxgb3/AUTHORS
rename to providers/cxgb4/AUTHORS
diff --git a/libcxgb4/src/CMakeLists.txt b/providers/cxgb4/CMakeLists.txt
similarity index 100%
rename from libcxgb4/src/CMakeLists.txt
rename to providers/cxgb4/CMakeLists.txt
diff --git a/libcxgb4/README b/providers/cxgb4/README
similarity index 100%
rename from libcxgb4/README
rename to providers/cxgb4/README
diff --git a/libcxgb4/src/cq.c b/providers/cxgb4/cq.c
similarity index 100%
rename from libcxgb4/src/cq.c
rename to providers/cxgb4/cq.c
diff --git a/libcxgb4/src/cxgb4-abi.h b/providers/cxgb4/cxgb4-abi.h
similarity index 100%
rename from libcxgb4/src/cxgb4-abi.h
rename to providers/cxgb4/cxgb4-abi.h
diff --git a/libcxgb4/src/dev.c b/providers/cxgb4/dev.c
similarity index 100%
rename from libcxgb4/src/dev.c
rename to providers/cxgb4/dev.c
diff --git a/libcxgb4/src/libcxgb4.h b/providers/cxgb4/libcxgb4.h
similarity index 100%
rename from libcxgb4/src/libcxgb4.h
rename to providers/cxgb4/libcxgb4.h
diff --git a/libcxgb4/src/qp.c b/providers/cxgb4/qp.c
similarity index 100%
rename from libcxgb4/src/qp.c
rename to providers/cxgb4/qp.c
diff --git a/libcxgb4/src/queue.h b/providers/cxgb4/queue.h
similarity index 100%
rename from libcxgb4/src/queue.h
rename to providers/cxgb4/queue.h
diff --git a/libcxgb4/src/t4.h b/providers/cxgb4/t4.h
similarity index 100%
rename from libcxgb4/src/t4.h
rename to providers/cxgb4/t4.h
diff --git a/libcxgb4/src/t4_chip_type.h b/providers/cxgb4/t4_chip_type.h
similarity index 100%
rename from libcxgb4/src/t4_chip_type.h
rename to providers/cxgb4/t4_chip_type.h
diff --git a/libcxgb4/src/t4_pci_id_tbl.h b/providers/cxgb4/t4_pci_id_tbl.h
similarity index 100%
rename from libcxgb4/src/t4_pci_id_tbl.h
rename to providers/cxgb4/t4_pci_id_tbl.h
diff --git a/libcxgb4/src/t4_regs.h b/providers/cxgb4/t4_regs.h
similarity index 100%
rename from libcxgb4/src/t4_regs.h
rename to providers/cxgb4/t4_regs.h
diff --git a/libcxgb4/src/t4fw_interface.h b/providers/cxgb4/t4fw_interface.h
similarity index 100%
rename from libcxgb4/src/t4fw_interface.h
rename to providers/cxgb4/t4fw_interface.h
diff --git a/libcxgb4/src/verbs.c b/providers/cxgb4/verbs.c
similarity index 100%
rename from libcxgb4/src/verbs.c
rename to providers/cxgb4/verbs.c
diff --git a/libhfi1verbs/AUTHORS b/providers/hfi1verbs/AUTHORS
similarity index 100%
rename from libhfi1verbs/AUTHORS
rename to providers/hfi1verbs/AUTHORS
diff --git a/libhfi1verbs/src/CMakeLists.txt b/providers/hfi1verbs/CMakeLists.txt
similarity index 100%
rename from libhfi1verbs/src/CMakeLists.txt
rename to providers/hfi1verbs/CMakeLists.txt
diff --git a/libhfi1verbs/COPYING b/providers/hfi1verbs/COPYING
similarity index 100%
rename from libhfi1verbs/COPYING
rename to providers/hfi1verbs/COPYING
diff --git a/libhfi1verbs/README b/providers/hfi1verbs/README
similarity index 100%
rename from libhfi1verbs/README
rename to providers/hfi1verbs/README
diff --git a/libhfi1verbs/src/hfi-abi.h b/providers/hfi1verbs/hfi-abi.h
similarity index 100%
rename from libhfi1verbs/src/hfi-abi.h
rename to providers/hfi1verbs/hfi-abi.h
diff --git a/libhfi1verbs/src/hfiverbs.c b/providers/hfi1verbs/hfiverbs.c
similarity index 100%
rename from libhfi1verbs/src/hfiverbs.c
rename to providers/hfi1verbs/hfiverbs.c
diff --git a/libhfi1verbs/src/hfiverbs.h b/providers/hfi1verbs/hfiverbs.h
similarity index 100%
rename from libhfi1verbs/src/hfiverbs.h
rename to providers/hfi1verbs/hfiverbs.h
diff --git a/libhfi1verbs/src/verbs.c b/providers/hfi1verbs/verbs.c
similarity index 100%
rename from libhfi1verbs/src/verbs.c
rename to providers/hfi1verbs/verbs.c
diff --git a/libnes/AUTHORS b/providers/i40iw/AUTHORS
similarity index 100%
rename from libnes/AUTHORS
rename to providers/i40iw/AUTHORS
diff --git a/libi40iw/src/CMakeLists.txt b/providers/i40iw/CMakeLists.txt
similarity index 100%
rename from libi40iw/src/CMakeLists.txt
rename to providers/i40iw/CMakeLists.txt
diff --git a/libi40iw/src/i40e_devids.h b/providers/i40iw/i40e_devids.h
similarity index 100%
rename from libi40iw/src/i40e_devids.h
rename to providers/i40iw/i40e_devids.h
diff --git a/libi40iw/src/i40iw-abi.h b/providers/i40iw/i40iw-abi.h
similarity index 100%
rename from libi40iw/src/i40iw-abi.h
rename to providers/i40iw/i40iw-abi.h
diff --git a/libi40iw/src/i40iw_d.h b/providers/i40iw/i40iw_d.h
similarity index 100%
rename from libi40iw/src/i40iw_d.h
rename to providers/i40iw/i40iw_d.h
diff --git a/libi40iw/src/i40iw_osdep.h b/providers/i40iw/i40iw_osdep.h
similarity index 100%
rename from libi40iw/src/i40iw_osdep.h
rename to providers/i40iw/i40iw_osdep.h
diff --git a/libi40iw/src/i40iw_register.h b/providers/i40iw/i40iw_register.h
similarity index 100%
rename from libi40iw/src/i40iw_register.h
rename to providers/i40iw/i40iw_register.h
diff --git a/libi40iw/src/i40iw_status.h b/providers/i40iw/i40iw_status.h
similarity index 100%
rename from libi40iw/src/i40iw_status.h
rename to providers/i40iw/i40iw_status.h
diff --git a/libi40iw/src/i40iw_uk.c b/providers/i40iw/i40iw_uk.c
similarity index 100%
rename from libi40iw/src/i40iw_uk.c
rename to providers/i40iw/i40iw_uk.c
diff --git a/libi40iw/src/i40iw_umain.c b/providers/i40iw/i40iw_umain.c
similarity index 100%
rename from libi40iw/src/i40iw_umain.c
rename to providers/i40iw/i40iw_umain.c
diff --git a/libi40iw/src/i40iw_umain.h b/providers/i40iw/i40iw_umain.h
similarity index 100%
rename from libi40iw/src/i40iw_umain.h
rename to providers/i40iw/i40iw_umain.h
diff --git a/libi40iw/src/i40iw_user.h b/providers/i40iw/i40iw_user.h
similarity index 100%
rename from libi40iw/src/i40iw_user.h
rename to providers/i40iw/i40iw_user.h
diff --git a/libi40iw/src/i40iw_uverbs.c b/providers/i40iw/i40iw_uverbs.c
similarity index 100%
rename from libi40iw/src/i40iw_uverbs.c
rename to providers/i40iw/i40iw_uverbs.c
diff --git a/libipathverbs/AUTHORS b/providers/ipathverbs/AUTHORS
similarity index 100%
rename from libipathverbs/AUTHORS
rename to providers/ipathverbs/AUTHORS
diff --git a/libipathverbs/CMakeLists.txt b/providers/ipathverbs/CMakeLists.txt
similarity index 80%
rename from libipathverbs/CMakeLists.txt
rename to providers/ipathverbs/CMakeLists.txt
index eba006e4c409..afebc36ec14f 100644
--- a/libipathverbs/CMakeLists.txt
+++ b/providers/ipathverbs/CMakeLists.txt
@@ -1,3 +1,7 @@
+rdma_provider(ipathverbs
+ ipathverbs.c
+ verbs.c
+ )
install(FILES truescale.conf DESTINATION "${SYSCONFDIR}/modprobe.d/")
install(FILES truescale-serdes.cmds
DESTINATION "sbin/"
diff --git a/libipathverbs/COPYING b/providers/ipathverbs/COPYING
similarity index 100%
rename from libipathverbs/COPYING
rename to providers/ipathverbs/COPYING
diff --git a/libipathverbs/README b/providers/ipathverbs/README
similarity index 100%
rename from libipathverbs/README
rename to providers/ipathverbs/README
diff --git a/libipathverbs/dracut_check b/providers/ipathverbs/dracut_check
similarity index 100%
rename from libipathverbs/dracut_check
rename to providers/ipathverbs/dracut_check
diff --git a/libipathverbs/dracut_install b/providers/ipathverbs/dracut_install
similarity index 100%
rename from libipathverbs/dracut_install
rename to providers/ipathverbs/dracut_install
diff --git a/libipathverbs/dracut_kmod b/providers/ipathverbs/dracut_kmod
similarity index 100%
rename from libipathverbs/dracut_kmod
rename to providers/ipathverbs/dracut_kmod
diff --git a/libipathverbs/src/ipath-abi.h b/providers/ipathverbs/ipath-abi.h
similarity index 100%
rename from libipathverbs/src/ipath-abi.h
rename to providers/ipathverbs/ipath-abi.h
diff --git a/libipathverbs/src/ipathverbs.c b/providers/ipathverbs/ipathverbs.c
similarity index 100%
rename from libipathverbs/src/ipathverbs.c
rename to providers/ipathverbs/ipathverbs.c
diff --git a/libipathverbs/src/ipathverbs.h b/providers/ipathverbs/ipathverbs.h
similarity index 100%
rename from libipathverbs/src/ipathverbs.h
rename to providers/ipathverbs/ipathverbs.h
diff --git a/libipathverbs/truescale-serdes.cmds b/providers/ipathverbs/truescale-serdes.cmds
similarity index 100%
rename from libipathverbs/truescale-serdes.cmds
rename to providers/ipathverbs/truescale-serdes.cmds
diff --git a/libipathverbs/truescale.conf b/providers/ipathverbs/truescale.conf
similarity index 100%
rename from libipathverbs/truescale.conf
rename to providers/ipathverbs/truescale.conf
diff --git a/libipathverbs/src/verbs.c b/providers/ipathverbs/verbs.c
similarity index 100%
rename from libipathverbs/src/verbs.c
rename to providers/ipathverbs/verbs.c
diff --git a/libmlx4/AUTHORS b/providers/mlx4/AUTHORS
similarity index 100%
rename from libmlx4/AUTHORS
rename to providers/mlx4/AUTHORS
diff --git a/libmlx4/src/CMakeLists.txt b/providers/mlx4/CMakeLists.txt
similarity index 100%
rename from libmlx4/src/CMakeLists.txt
rename to providers/mlx4/CMakeLists.txt
diff --git a/libmlx4/README b/providers/mlx4/README
similarity index 100%
rename from libmlx4/README
rename to providers/mlx4/README
diff --git a/libmlx4/src/buf.c b/providers/mlx4/buf.c
similarity index 100%
rename from libmlx4/src/buf.c
rename to providers/mlx4/buf.c
diff --git a/libmlx4/src/cq.c b/providers/mlx4/cq.c
similarity index 100%
rename from libmlx4/src/cq.c
rename to providers/mlx4/cq.c
diff --git a/libmlx4/src/dbrec.c b/providers/mlx4/dbrec.c
similarity index 100%
rename from libmlx4/src/dbrec.c
rename to providers/mlx4/dbrec.c
diff --git a/libmlx4/src/doorbell.h b/providers/mlx4/doorbell.h
similarity index 100%
rename from libmlx4/src/doorbell.h
rename to providers/mlx4/doorbell.h
diff --git a/libmlx4/src/mlx4-abi.h b/providers/mlx4/mlx4-abi.h
similarity index 100%
rename from libmlx4/src/mlx4-abi.h
rename to providers/mlx4/mlx4-abi.h
diff --git a/libmlx4/src/mlx4.c b/providers/mlx4/mlx4.c
similarity index 100%
rename from libmlx4/src/mlx4.c
rename to providers/mlx4/mlx4.c
diff --git a/libmlx4/src/mlx4.h b/providers/mlx4/mlx4.h
similarity index 100%
rename from libmlx4/src/mlx4.h
rename to providers/mlx4/mlx4.h
diff --git a/libmlx4/src/mmio.h b/providers/mlx4/mmio.h
similarity index 100%
rename from libmlx4/src/mmio.h
rename to providers/mlx4/mmio.h
diff --git a/libmlx4/src/qp.c b/providers/mlx4/qp.c
similarity index 100%
rename from libmlx4/src/qp.c
rename to providers/mlx4/qp.c
diff --git a/libmlx4/src/srq.c b/providers/mlx4/srq.c
similarity index 100%
rename from libmlx4/src/srq.c
rename to providers/mlx4/srq.c
diff --git a/libmlx4/src/verbs.c b/providers/mlx4/verbs.c
similarity index 100%
rename from libmlx4/src/verbs.c
rename to providers/mlx4/verbs.c
diff --git a/libmlx4/src/wqe.h b/providers/mlx4/wqe.h
similarity index 100%
rename from libmlx4/src/wqe.h
rename to providers/mlx4/wqe.h
diff --git a/libmlx5/AUTHORS b/providers/mlx5/AUTHORS
similarity index 100%
rename from libmlx5/AUTHORS
rename to providers/mlx5/AUTHORS
diff --git a/libmlx5/src/CMakeLists.txt b/providers/mlx5/CMakeLists.txt
similarity index 100%
rename from libmlx5/src/CMakeLists.txt
rename to providers/mlx5/CMakeLists.txt
diff --git a/libmlx5/README b/providers/mlx5/README
similarity index 100%
rename from libmlx5/README
rename to providers/mlx5/README
diff --git a/libmlx5/src/bitmap.h b/providers/mlx5/bitmap.h
similarity index 100%
rename from libmlx5/src/bitmap.h
rename to providers/mlx5/bitmap.h
diff --git a/libmlx5/src/buf.c b/providers/mlx5/buf.c
similarity index 100%
rename from libmlx5/src/buf.c
rename to providers/mlx5/buf.c
diff --git a/libmlx5/src/cq.c b/providers/mlx5/cq.c
similarity index 100%
rename from libmlx5/src/cq.c
rename to providers/mlx5/cq.c
diff --git a/libmlx5/src/dbrec.c b/providers/mlx5/dbrec.c
similarity index 100%
rename from libmlx5/src/dbrec.c
rename to providers/mlx5/dbrec.c
diff --git a/libmlx5/src/doorbell.h b/providers/mlx5/doorbell.h
similarity index 100%
rename from libmlx5/src/doorbell.h
rename to providers/mlx5/doorbell.h
diff --git a/libmlx5/src/list.h b/providers/mlx5/list.h
similarity index 100%
rename from libmlx5/src/list.h
rename to providers/mlx5/list.h
diff --git a/libmlx5/src/mlx5-abi.h b/providers/mlx5/mlx5-abi.h
similarity index 100%
rename from libmlx5/src/mlx5-abi.h
rename to providers/mlx5/mlx5-abi.h
diff --git a/libmlx5/src/mlx5.c b/providers/mlx5/mlx5.c
similarity index 100%
rename from libmlx5/src/mlx5.c
rename to providers/mlx5/mlx5.c
diff --git a/libmlx5/src/mlx5.h b/providers/mlx5/mlx5.h
similarity index 100%
rename from libmlx5/src/mlx5.h
rename to providers/mlx5/mlx5.h
diff --git a/libmlx5/src/qp.c b/providers/mlx5/qp.c
similarity index 100%
rename from libmlx5/src/qp.c
rename to providers/mlx5/qp.c
diff --git a/libmlx5/src/srq.c b/providers/mlx5/srq.c
similarity index 100%
rename from libmlx5/src/srq.c
rename to providers/mlx5/srq.c
diff --git a/libmlx5/src/verbs.c b/providers/mlx5/verbs.c
similarity index 100%
rename from libmlx5/src/verbs.c
rename to providers/mlx5/verbs.c
diff --git a/libmlx5/src/wqe.h b/providers/mlx5/wqe.h
similarity index 100%
rename from libmlx5/src/wqe.h
rename to providers/mlx5/wqe.h
diff --git a/libmthca/AUTHORS b/providers/mthca/AUTHORS
similarity index 100%
rename from libmthca/AUTHORS
rename to providers/mthca/AUTHORS
diff --git a/libmthca/src/CMakeLists.txt b/providers/mthca/CMakeLists.txt
similarity index 100%
rename from libmthca/src/CMakeLists.txt
rename to providers/mthca/CMakeLists.txt
diff --git a/libmthca/README b/providers/mthca/README
similarity index 100%
rename from libmthca/README
rename to providers/mthca/README
diff --git a/libmthca/src/ah.c b/providers/mthca/ah.c
similarity index 100%
rename from libmthca/src/ah.c
rename to providers/mthca/ah.c
diff --git a/libmthca/src/buf.c b/providers/mthca/buf.c
similarity index 100%
rename from libmthca/src/buf.c
rename to providers/mthca/buf.c
diff --git a/libmthca/src/cq.c b/providers/mthca/cq.c
similarity index 100%
rename from libmthca/src/cq.c
rename to providers/mthca/cq.c
diff --git a/libmthca/src/doorbell.h b/providers/mthca/doorbell.h
similarity index 100%
rename from libmthca/src/doorbell.h
rename to providers/mthca/doorbell.h
diff --git a/libmthca/src/memfree.c b/providers/mthca/memfree.c
similarity index 100%
rename from libmthca/src/memfree.c
rename to providers/mthca/memfree.c
diff --git a/libmthca/src/mthca-abi.h b/providers/mthca/mthca-abi.h
similarity index 100%
rename from libmthca/src/mthca-abi.h
rename to providers/mthca/mthca-abi.h
diff --git a/libmthca/src/mthca.c b/providers/mthca/mthca.c
similarity index 100%
rename from libmthca/src/mthca.c
rename to providers/mthca/mthca.c
diff --git a/libmthca/src/mthca.h b/providers/mthca/mthca.h
similarity index 100%
rename from libmthca/src/mthca.h
rename to providers/mthca/mthca.h
diff --git a/libmthca/src/qp.c b/providers/mthca/qp.c
similarity index 100%
rename from libmthca/src/qp.c
rename to providers/mthca/qp.c
diff --git a/libmthca/src/srq.c b/providers/mthca/srq.c
similarity index 100%
rename from libmthca/src/srq.c
rename to providers/mthca/srq.c
diff --git a/libmthca/src/verbs.c b/providers/mthca/verbs.c
similarity index 100%
rename from libmthca/src/verbs.c
rename to providers/mthca/verbs.c
diff --git a/libmthca/src/wqe.h b/providers/mthca/wqe.h
similarity index 100%
rename from libmthca/src/wqe.h
rename to providers/mthca/wqe.h
diff --git a/libi40iw/AUTHORS b/providers/nes/AUTHORS
similarity index 100%
rename from libi40iw/AUTHORS
rename to providers/nes/AUTHORS
diff --git a/libnes/src/CMakeLists.txt b/providers/nes/CMakeLists.txt
similarity index 100%
rename from libnes/src/CMakeLists.txt
rename to providers/nes/CMakeLists.txt
diff --git a/libnes/COPYING b/providers/nes/COPYING
similarity index 100%
rename from libnes/COPYING
rename to providers/nes/COPYING
diff --git a/libnes/src/nes-abi.h b/providers/nes/nes-abi.h
similarity index 100%
rename from libnes/src/nes-abi.h
rename to providers/nes/nes-abi.h
diff --git a/libnes/src/nes_umain.c b/providers/nes/nes_umain.c
similarity index 100%
rename from libnes/src/nes_umain.c
rename to providers/nes/nes_umain.c
diff --git a/libnes/src/nes_umain.h b/providers/nes/nes_umain.h
similarity index 100%
rename from libnes/src/nes_umain.h
rename to providers/nes/nes_umain.h
diff --git a/libnes/src/nes_uverbs.c b/providers/nes/nes_uverbs.c
similarity index 100%
rename from libnes/src/nes_uverbs.c
rename to providers/nes/nes_uverbs.c
diff --git a/libocrdma/AUTHORS b/providers/ocrdma/AUTHORS
similarity index 100%
rename from libocrdma/AUTHORS
rename to providers/ocrdma/AUTHORS
diff --git a/libocrdma/src/CMakeLists.txt b/providers/ocrdma/CMakeLists.txt
similarity index 100%
rename from libocrdma/src/CMakeLists.txt
rename to providers/ocrdma/CMakeLists.txt
diff --git a/libocrdma/Changelog b/providers/ocrdma/Changelog
similarity index 100%
rename from libocrdma/Changelog
rename to providers/ocrdma/Changelog
diff --git a/libocrdma/README b/providers/ocrdma/README
similarity index 100%
rename from libocrdma/README
rename to providers/ocrdma/README
diff --git a/libocrdma/src/ocrdma_abi.h b/providers/ocrdma/ocrdma_abi.h
similarity index 100%
rename from libocrdma/src/ocrdma_abi.h
rename to providers/ocrdma/ocrdma_abi.h
diff --git a/libocrdma/src/ocrdma_list.h b/providers/ocrdma/ocrdma_list.h
similarity index 100%
rename from libocrdma/src/ocrdma_list.h
rename to providers/ocrdma/ocrdma_list.h
diff --git a/libocrdma/src/ocrdma_main.c b/providers/ocrdma/ocrdma_main.c
similarity index 100%
rename from libocrdma/src/ocrdma_main.c
rename to providers/ocrdma/ocrdma_main.c
diff --git a/libocrdma/src/ocrdma_main.h b/providers/ocrdma/ocrdma_main.h
similarity index 100%
rename from libocrdma/src/ocrdma_main.h
rename to providers/ocrdma/ocrdma_main.h
diff --git a/libocrdma/src/ocrdma_verbs.c b/providers/ocrdma/ocrdma_verbs.c
similarity index 100%
rename from libocrdma/src/ocrdma_verbs.c
rename to providers/ocrdma/ocrdma_verbs.c
diff --git a/librxe/CMakeLists.txt b/providers/rxe/CMakeLists.txt
similarity index 82%
rename from librxe/CMakeLists.txt
rename to providers/rxe/CMakeLists.txt
index d736c67e53d9..2b6a236db0de 100644
--- a/librxe/CMakeLists.txt
+++ b/providers/rxe/CMakeLists.txt
@@ -1,3 +1,6 @@
+rdma_provider(rxe
+ rxe.c
+ )
install(FILES rxe_cfg
DESTINATION bin/
PERMISSIONS OWNER_WRITE OWNER_READ GROUP_READ WORLD_READ OWNER_EXECUTE GROUP_EXECUTE WORLD_EXECUTE
diff --git a/librxe/README.md b/providers/rxe/README.md
similarity index 100%
rename from librxe/README.md
rename to providers/rxe/README.md
diff --git a/librxe/man/CMakeLists.txt b/providers/rxe/man/CMakeLists.txt
similarity index 100%
rename from librxe/man/CMakeLists.txt
rename to providers/rxe/man/CMakeLists.txt
diff --git a/librxe/man/rxe.7 b/providers/rxe/man/rxe.7
similarity index 100%
rename from librxe/man/rxe.7
rename to providers/rxe/man/rxe.7
diff --git a/librxe/man/rxe_cfg.8 b/providers/rxe/man/rxe_cfg.8
similarity index 100%
rename from librxe/man/rxe_cfg.8
rename to providers/rxe/man/rxe_cfg.8
diff --git a/librxe/src/rxe-abi.h b/providers/rxe/rxe-abi.h
similarity index 100%
rename from librxe/src/rxe-abi.h
rename to providers/rxe/rxe-abi.h
diff --git a/librxe/src/rxe.c b/providers/rxe/rxe.c
similarity index 100%
rename from librxe/src/rxe.c
rename to providers/rxe/rxe.c
diff --git a/librxe/src/rxe.h b/providers/rxe/rxe.h
similarity index 100%
rename from librxe/src/rxe.h
rename to providers/rxe/rxe.h
diff --git a/librxe/rxe_cfg b/providers/rxe/rxe_cfg
similarity index 100%
rename from librxe/rxe_cfg
rename to providers/rxe/rxe_cfg
diff --git a/librxe/src/rxe_queue.h b/providers/rxe/rxe_queue.h
similarity index 100%
rename from librxe/src/rxe_queue.h
rename to providers/rxe/rxe_queue.h
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* [RFCv2 15/15] Add a MAINTAINERS file
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (13 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 14/15] Move providers into providers/ Jason Gunthorpe
@ 2016-08-22 18:13 ` Jason Gunthorpe
2016-08-22 20:06 ` [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo Steve Wise
` (3 subsequent siblings)
18 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 18:13 UTC (permalink / raw)
To: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
This is in the same format as the Kernel's version of this file
and reflects who is responsible for each portion of the tree.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
MAINTAINERS | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
create mode 100644 MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 000000000000..8013c42ef245
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,81 @@
+BUILD SYSTEM
+M: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
+S: Supported
+F: */CMakeLists.txt
+F: buildlib/
+
+CXGB3 USERSPACE PROVIDER (for iw_cxgb3.ko)
+M: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
+S: Supported
+F: providers/cxgb3/
+
+CXGB4 USERSPACE PROVIDER (for iw_cxgb4.ko)
+M: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
+S: Supported
+F: providers/cxgb4/
+
+HF1 USERSPACE PROVIDER (for hf1.ko)
+M: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+S: Supported
+L: intel-opa-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org
+F: providers/hfi1verbs/
+
+I40IW USERSPACE PROVIDER (for i40iw.ko)
+M: Tatyana Nikolova <Tatyana.E.Nikolova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+S: Supported
+F: providers/i40iw/
+
+IPATH/QIB USERSPACE PROVIDER (for ib_qib.ko)
+M: Mike Marciniszyn <mike.marciniszyn-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+S: Supported
+F: providers/ipathverbs/
+
+LIBIBCM USERSPACE LIBRARY FOR IB CONNECTION MANAGEMENT (/dev/infiniband/ucmX)
+M: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+S: Obsolete
+F: libibcm/
+
+LIBIBUMAD USERSPACE LIBRARY FOR SMP AND GMP MAD PROCESSING (/dev/infiniband/umadX)
+M: Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
+S: Supported
+F: libibumad/
+
+LIBIBVERBS USERSPACE LIBRARY FOR RDMA VERBS (/dev/infiniband/uverbsX)
+M: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+S: Supported
+F: libibverbs/
+
+LIBRDMACM USERSPACE LIBRARY FOR RDMA CONNECTION MANAGEMENT (/dev/infiniband/rdma_cm)
+M: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+S: Supported
+F: librdmacm/
+
+MLX4 USERSPACE PROVIDER (for mlx4_ib.ko)
+M: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
+S: Supported
+F: providers/mlx4/
+
+MLX5 USERSPACE PROVIDER (for mlx5_ib.ko)
+M: Yishai Hadas <yishaih-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
+S: Supported
+F: providers/mlx5/
+
+MTHCA USERSPACE PROVIDER (for ib_mthca.ko)
+M: Vladimir Sokolovsky <vlad-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
+S: Supported
+F: providers/mthca/
+
+NES USERSPACE PROVIDER (for iw_nes.ko)
+M: Tatyana Nikolova <Tatyana.E.Nikolova-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
+S: Supported
+F: providers/nes/
+
+OCRDMA USERSPACE PROVIDER (for ocrdma.ko)
+M: Devesh Sharma <Devesh.sharma-laKkSmNT4hbQT0dZR+AlfA@public.gmane.org>
+S: Supported
+F: providers/ocrdma/
+
+RXE SOFT ROCEE USERSPACE PROVIDER (for rdma_rxe.ko)
+M: Moni Shoua <monis-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
+S: Supported
+F: providers/rxe/
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (14 preceding siblings ...)
2016-08-22 18:13 ` [RFCv2 15/15] Add a MAINTAINERS file Jason Gunthorpe
@ 2016-08-22 20:06 ` Steve Wise
2016-08-22 20:12 ` Steve Wise
2016-08-22 21:43 ` Jason Gunthorpe
2016-09-01 15:24 ` Sagi Grimberg
` (2 subsequent siblings)
18 siblings, 2 replies; 174+ messages in thread
From: Steve Wise @ 2016-08-22 20:06 UTC (permalink / raw)
To: 'Jason Gunthorpe', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: 'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
>
> Hello Everyone,
>
> Here is the patch series for the consolidation. This is based on the special
> merge commit created by the buildlib/make-merge.py script. See my prior
> message (http://www.spinics.net/lists/linux-rdma/msg39026.html) for details.
>
> The first 7 patches change/fix various things in the original packages to
> build consistently, patch 8 has cmake and all the auto* co-exist, and can be
> used to do build compares (see buildlib/compare-build.py)
>
> The next batch of patches removes the old build stuff, packaging, merges
> COPYING files and lightly simplifies the directory structure.
>
> https://github.com/jgunthorpe/rdma-plumbing
>
Hey Jason, following your RHEL6 instructions from README.md, I was able to build
everything fine. I'm amazed at how fast it builds...
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-08-22 20:06 ` [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo Steve Wise
@ 2016-08-22 20:12 ` Steve Wise
2016-08-22 21:43 ` Jason Gunthorpe
1 sibling, 0 replies; 174+ messages in thread
From: Steve Wise @ 2016-08-22 20:12 UTC (permalink / raw)
To: 'Jason Gunthorpe', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: 'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
> > Hello Everyone,
> >
> > Here is the patch series for the consolidation. This is based on the special
> > merge commit created by the buildlib/make-merge.py script. See my prior
> > message (http://www.spinics.net/lists/linux-rdma/msg39026.html) for details.
> >
> > The first 7 patches change/fix various things in the original packages to
> > build consistently, patch 8 has cmake and all the auto* co-exist, and can be
> > used to do build compares (see buildlib/compare-build.py)
> >
> > The next batch of patches removes the old build stuff, packaging, merges
> > COPYING files and lightly simplifies the directory structure.
> >
> > https://github.com/jgunthorpe/rdma-plumbing
> >
>
> Hey Jason, following your RHEL6 instructions from README.md, I was able to
build
> everything fine. I'm amazed at how fast it builds...
>
> Steve.
Also, what is the command to install all the cmds/libs?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-08-22 20:06 ` [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo Steve Wise
2016-08-22 20:12 ` Steve Wise
@ 2016-08-22 21:43 ` Jason Gunthorpe
[not found] ` <20160822214352.GB11695-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-22 21:43 UTC (permalink / raw)
To: Steve Wise
Cc: 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Mon, Aug 22, 2016 at 03:06:13PM -0500, Steve Wise wrote:
> Hey Jason, following your RHEL6 instructions from README.md, I was able to build
> everything fine. I'm amazed at how fast it builds...
Yes, it really is a better developer experience, and you probably
didn't notice that ninja automatically does stuff like 'make -O' (and
it actually fully works) and tracks changes to the build commands
(like kbuild).. For those reading my system can go from a clean git
checkout to a full build of all 15 libraries in 3.5s.
The install is done in the usual way:
(make or ninja) install
DESTDIR environment var works as usual for packagers.
That does exactly the same as 'make install' did for auto*, which is,
IMHO, somewhat useless since it goes into /usr/local.
The full install to / is still a small TODO, it is part and parcel
with doing the packaging, in my mind.
But the basic starting point is:
cmake .. -DCMAKE_SKIP_RPATH=ON -DCMAKE_INSTALL_PREFIX=/usr
But a bit more work is needed to make SYSCONFDIR work right..
I also want to make a patch to 'run in place' (eg with
LD_LIBRARY_PATH), which makes sense now that the providers build
along-side libverbs.
It isn't too hard but lets get agreement on this direction at all
first...
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160822214352.GB11695-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-23 18:54 ` Jason Gunthorpe
[not found] ` <20160823185441.GA1233-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-23 18:54 UTC (permalink / raw)
To: Steve Wise
Cc: 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
> The full install to / is still a small TODO, it is part and parcel
> with doing the packaging, in my mind.
I just pushed a basic starting point rpm spec file, it still needs to
be split into multiple subpackages, but it is installable with all the
usual paths.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160823185441.GA1233-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-25 14:20 ` Doug Ledford
[not found] ` <cabbd0a7-0918-a8dd-d1e5-0b079f0c4604-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-08-25 14:20 UTC (permalink / raw)
To: Jason Gunthorpe, Steve Wise
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 843 bytes --]
On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
> On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
>
>> The full install to / is still a small TODO, it is part and parcel
>> with doing the packaging, in my mind.
>
> I just pushed a basic starting point rpm spec file, it still needs to
> be split into multiple subpackages, but it is installable with all the
> usual paths.
You can do that, but I routinely tell upstream maintainers that we don't
touch their spec files. Every distro modifies the spec file so heavily
for their own custom installation that it just doesn't make much sense
to worry about it at the upstream level. Build one that can be used
when running rpmbuild -ta and that's all you need.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <cabbd0a7-0918-a8dd-d1e5-0b079f0c4604-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-25 14:22 ` Doug Ledford
[not found] ` <f98718ea-72b5-e157-5f16-14ca51a85c53-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-25 17:39 ` Jason Gunthorpe
2016-08-28 16:14 ` Yishai Hadas
2 siblings, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-08-25 14:22 UTC (permalink / raw)
To: Jason Gunthorpe, Steve Wise
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 1113 bytes --]
On 8/25/2016 10:20 AM, Doug Ledford wrote:
> On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
>> On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
>>
>>> The full install to / is still a small TODO, it is part and parcel
>>> with doing the packaging, in my mind.
>>
>> I just pushed a basic starting point rpm spec file, it still needs to
>> be split into multiple subpackages, but it is installable with all the
>> usual paths.
>
> You can do that, but I routinely tell upstream maintainers that we don't
> touch their spec files. Every distro modifies the spec file so heavily
> for their own custom installation that it just doesn't make much sense
> to worry about it at the upstream level. Build one that can be used
> when running rpmbuild -ta and that's all you need.
>
>
Also, patchworks dropped all of the patches that were pure deletes.
Seems if there isn't some sort of patch to go along with the git delete
or chmod commands, it doesn't think it's a real patch.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <f98718ea-72b5-e157-5f16-14ca51a85c53-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-25 16:47 ` Jason Gunthorpe
[not found] ` <20160825164753.GB20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-25 16:47 UTC (permalink / raw)
To: Doug Ledford
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Thu, Aug 25, 2016 at 10:22:06AM -0400, Doug Ledford wrote:
> Also, patchworks dropped all of the patches that were pure deletes.
> Seems if there isn't some sort of patch to go along with the git delete
> or chmod commands, it doesn't think it's a real patch.
Hmm, is this a problem? I don't expect patchworks will be useful for
the initial repository setup, as the special merge commit
(e4a0ff72cfd8) cannot be sent as a patch, and all patches are on top
of that.
It would be easiest to pull from my github with a signed tag or
something. This is why I elided the content of the deletes for
readability (there is 54kloc deleted)
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <cabbd0a7-0918-a8dd-d1e5-0b079f0c4604-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-25 14:22 ` Doug Ledford
@ 2016-08-25 17:39 ` Jason Gunthorpe
[not found] ` <20160825173916.GC20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-28 16:14 ` Yishai Hadas
2 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-25 17:39 UTC (permalink / raw)
To: Doug Ledford
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Thu, Aug 25, 2016 at 10:20:15AM -0400, Doug Ledford wrote:
> On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
> > On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
> >
> >> The full install to / is still a small TODO, it is part and parcel
> >> with doing the packaging, in my mind.
> >
> > I just pushed a basic starting point rpm spec file, it still needs to
> > be split into multiple subpackages, but it is installable with all the
> > usual paths.
>
> You can do that, but I routinely tell upstream maintainers that we don't
> touch their spec files. Every distro modifies the spec file so heavily
> for their own custom installation that it just doesn't make much sense
> to worry about it at the upstream level. Build one that can be used
> when running rpmbuild -ta and that's all you need.
I'm not sure I understand your comment.
Are you saying we don't need a specfile in upstream? How does upstream
test the build infrastructure?
Are you saying the simple one .rpm is all we need? Is that really
useful to developers if it clashes with the distro packaging? How do
we test the build system parts that help the package splitting?
Isn't it easier for downstream to have recommended packaging to
reference?
Eg I think it was a dis-service to other distros not to update the
reference verbs spec file with the libnl dependency. I wonder how many
downstreams noticed this change and are still building verbs properly?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160825173916.GC20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-25 19:52 ` Jarod Wilson
[not found] ` <20160825195246.GI1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-27 3:34 ` Doug Ledford
1 sibling, 1 reply; 174+ messages in thread
From: Jarod Wilson @ 2016-08-25 19:52 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Thu, Aug 25, 2016 at 11:39:16AM -0600, Jason Gunthorpe wrote:
> On Thu, Aug 25, 2016 at 10:20:15AM -0400, Doug Ledford wrote:
> > On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
> > > On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
> > >
> > >> The full install to / is still a small TODO, it is part and parcel
> > >> with doing the packaging, in my mind.
> > >
> > > I just pushed a basic starting point rpm spec file, it still needs to
> > > be split into multiple subpackages, but it is installable with all the
> > > usual paths.
> >
> > You can do that, but I routinely tell upstream maintainers that we don't
> > touch their spec files. Every distro modifies the spec file so heavily
> > for their own custom installation that it just doesn't make much sense
> > to worry about it at the upstream level. Build one that can be used
> > when running rpmbuild -ta and that's all you need.
>
> I'm not sure I understand your comment.
>
> Are you saying we don't need a specfile in upstream?
Distros certainly don't require it.
> How does upstream
> test the build infrastructure?
./configure, make, make install (or cmake/ninja/whatever)
> Are you saying the simple one .rpm is all we need? Is that really
> useful to developers if it clashes with the distro packaging? How do
> we test the build system parts that help the package splitting?
I either build locally in the git tree(s) and run from there, or I take
the upstream tarball and modify my distro spec file to use it.
> Isn't it easier for downstream to have recommended packaging to
> reference?
Generally, no, because various upstreams often do things that violate the
packaging rules for a given distro. Upstream specs are occasionally used
for reference bringing up a new package, but at least for Red Hat and
Fedora, it's 100% of the time a distro-maintained spec file used, not the
upstream one. Among other reasons, we add changelog entries when a package
is rebuilt, often referencing a bugzilla number and what exactly was
fixed, rather than just "update to new version" entries. These specs tend
to get carried forward over time and releases, rather than throwing them
out and replacing them with something from upstream.
> Eg I think it was a dis-service to other distros not to update the
> reference verbs spec file with the libnl dependency. I wonder how many
> downstreams noticed this change and are still building verbs properly?
Add the dependency to the build infra, and problem solved for rpm, deb,
whatever other packaging system. Updating the spec only helps rpm-based
distros, maybe, if they use the spec (which RH/Fedora doesn't).
--
Jarod Wilson
jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160825195246.GI1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-25 20:13 ` Jason Gunthorpe
[not found] ` <20160825201306.GA5421-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-25 20:13 UTC (permalink / raw)
To: Jarod Wilson
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Thu, Aug 25, 2016 at 03:52:46PM -0400, Jarod Wilson wrote:
> On Thu, Aug 25, 2016 at 11:39:16AM -0600, Jason Gunthorpe wrote:
> > On Thu, Aug 25, 2016 at 10:20:15AM -0400, Doug Ledford wrote:
> > > On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
> > > > On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
> > > >
> > > >> The full install to / is still a small TODO, it is part and parcel
> > > >> with doing the packaging, in my mind.
> > > >
> > > > I just pushed a basic starting point rpm spec file, it still needs to
> > > > be split into multiple subpackages, but it is installable with all the
> > > > usual paths.
> > >
> > > You can do that, but I routinely tell upstream maintainers that we don't
> > > touch their spec files. Every distro modifies the spec file so heavily
> > > for their own custom installation that it just doesn't make much sense
> > > to worry about it at the upstream level. Build one that can be used
> > > when running rpmbuild -ta and that's all you need.
> >
> > I'm not sure I understand your comment.
> >
> > Are you saying we don't need a specfile in upstream?
>
> Distros certainly don't require it.
I know that, my question is poised to the larger developer community
who need to build test and deploy this stuff as not-a-distro.
> > How does upstream
> > test the build infrastructure?
>
> ./configure, make, make install (or cmake/ninja/whatever)
rpmbuild does stuff that needs to be checked out and validated by
upstream at least occasionally, or packaging becomes too hard for the
downstream because of broken build infra.
> I either build locally in the git tree(s) and run from there, or I take
> the upstream tarball and modify my distro spec file to use it.
We've never been able to run the rdma stack from the build trees, the
dlopen stuff and the split packaging made it too hard. We can almost
do it with the unified tree, but that is still a few patches away.. So
that isn't a good answer for developers.
> Generally, no, because various upstreams often do things that violate the
> packaging rules for a given distro. Upstream specs are occasionally used
> for reference bringing up a new package, but at least for Red Hat
> and
Well, that is exactly where we are right now, bringing up a new
(complex) package.
Would you help making a spec file that is close to what you
could use in the distro? I don't really care if it is stored in the
package or stored inside RH, but we need to get one made.
> > Eg I think it was a dis-service to other distros not to update the
> > reference verbs spec file with the libnl dependency. I wonder how many
> > downstreams noticed this change and are still building verbs properly?
>
> Add the dependency to the build infra, and problem solved for rpm, deb,
> whatever other packaging system. Updating the spec only helps rpm-based
> distros, maybe, if they use the spec (which RH/Fedora doesn't).
The build infra has an optional requirement for libnl3, and other
things.
I don't know why we did that, maybe it should have been mandatory, but
the point remains, it is a subtle change that is easy to miss
downstream. Presumably downstream folks review changes to the tarball
including the reference spec file before packaging a new version?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160825201306.GA5421-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-25 20:32 ` Steve Wise
2016-08-26 15:42 ` Jarod Wilson
2016-08-27 3:17 ` Doug Ledford
2 siblings, 0 replies; 174+ messages in thread
From: Steve Wise @ 2016-08-25 20:32 UTC (permalink / raw)
To: 'Jason Gunthorpe', 'Jarod Wilson'
Cc: 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
> On Thu, Aug 25, 2016 at 03:52:46PM -0400, Jarod Wilson wrote:
> > On Thu, Aug 25, 2016 at 11:39:16AM -0600, Jason Gunthorpe wrote:
> > > On Thu, Aug 25, 2016 at 10:20:15AM -0400, Doug Ledford wrote:
> > > > On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
> > > > > On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
> > > > >
> > > > >> The full install to / is still a small TODO, it is part and parcel
> > > > >> with doing the packaging, in my mind.
> > > > >
> > > > > I just pushed a basic starting point rpm spec file, it still needs to
> > > > > be split into multiple subpackages, but it is installable with all the
> > > > > usual paths.
> > > >
> > > > You can do that, but I routinely tell upstream maintainers that we don't
> > > > touch their spec files. Every distro modifies the spec file so heavily
> > > > for their own custom installation that it just doesn't make much sense
> > > > to worry about it at the upstream level. Build one that can be used
> > > > when running rpmbuild -ta and that's all you need.
> > >
> > > I'm not sure I understand your comment.
> > >
> > > Are you saying we don't need a specfile in upstream?
> >
> > Distros certainly don't require it.
>
> I know that, my question is poised to the larger developer community
> who need to build test and deploy this stuff as not-a-distro.
>
I always ./autogen.sh, then ./configure, then make && make install.
> > > How does upstream
> > > test the build infrastructure?
> >
> > ./configure, make, make install (or cmake/ninja/whatever)
>
> rpmbuild does stuff that needs to be checked out and validated by
> upstream at least occasionally, or packaging becomes too hard for the
> downstream because of broken build infra.
>
> > I either build locally in the git tree(s) and run from there, or I take
> > the upstream tarball and modify my distro spec file to use it.
>
> We've never been able to run the rdma stack from the build trees, the
> dlopen stuff and the split packaging made it too hard. We can almost
> do it with the unified tree, but that is still a few patches away.. So
> that isn't a good answer for developers.
>
> > Generally, no, because various upstreams often do things that violate the
> > packaging rules for a given distro. Upstream specs are occasionally used
> > for reference bringing up a new package, but at least for Red Hat
> > and
>
> Well, that is exactly where we are right now, bringing up a new
> (complex) package.
>
> Would you help making a spec file that is close to what you
> could use in the distro? I don't really care if it is stored in the
> package or stored inside RH, but we need to get one made.
>
> > > Eg I think it was a dis-service to other distros not to update the
> > > reference verbs spec file with the libnl dependency. I wonder how many
> > > downstreams noticed this change and are still building verbs properly?
> >
> > Add the dependency to the build infra, and problem solved for rpm, deb,
> > whatever other packaging system. Updating the spec only helps rpm-based
> > distros, maybe, if they use the spec (which RH/Fedora doesn't).
>
> The build infra has an optional requirement for libnl3, and other
> things.
>
> I don't know why we did that, maybe it should have been mandatory, but
> the point remains, it is a subtle change that is easy to miss
> downstream. Presumably downstream folks review changes to the tarball
> including the reference spec file before packaging a new version?
>
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160825201306.GA5421-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-25 20:32 ` Steve Wise
@ 2016-08-26 15:42 ` Jarod Wilson
[not found] ` <20160826154206.GK1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-27 3:17 ` Doug Ledford
2 siblings, 1 reply; 174+ messages in thread
From: Jarod Wilson @ 2016-08-26 15:42 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Thu, Aug 25, 2016 at 02:13:06PM -0600, Jason Gunthorpe wrote:
> On Thu, Aug 25, 2016 at 03:52:46PM -0400, Jarod Wilson wrote:
> > On Thu, Aug 25, 2016 at 11:39:16AM -0600, Jason Gunthorpe wrote:
> > > On Thu, Aug 25, 2016 at 10:20:15AM -0400, Doug Ledford wrote:
> > > > On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
> > > > > On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
> > > > >
> > > > >> The full install to / is still a small TODO, it is part and parcel
> > > > >> with doing the packaging, in my mind.
> > > > >
> > > > > I just pushed a basic starting point rpm spec file, it still needs to
> > > > > be split into multiple subpackages, but it is installable with all the
> > > > > usual paths.
> > > >
> > > > You can do that, but I routinely tell upstream maintainers that we don't
> > > > touch their spec files. Every distro modifies the spec file so heavily
> > > > for their own custom installation that it just doesn't make much sense
> > > > to worry about it at the upstream level. Build one that can be used
> > > > when running rpmbuild -ta and that's all you need.
> > >
> > > I'm not sure I understand your comment.
> > >
> > > Are you saying we don't need a specfile in upstream?
> >
> > Distros certainly don't require it.
>
> I know that, my question is poised to the larger developer community
> who need to build test and deploy this stuff as not-a-distro.
>
> > > How does upstream
> > > test the build infrastructure?
> >
> > ./configure, make, make install (or cmake/ninja/whatever)
>
> rpmbuild does stuff that needs to be checked out and validated by
> upstream at least occasionally, or packaging becomes too hard for the
> downstream because of broken build infra.
A good downstream ought to be reporting any issues they encounter, so I
think you can more or less offload that burden until such time as someone
comes and says "hey, you just broke xyz".
> > I either build locally in the git tree(s) and run from there, or I take
> > the upstream tarball and modify my distro spec file to use it.
>
> We've never been able to run the rdma stack from the build trees, the
> dlopen stuff and the split packaging made it too hard. We can almost
> do it with the unified tree, but that is still a few patches away.. So
> that isn't a good answer for developers.
I usually rpmbuild and install libs, run various test apps, etc., from
local git tree builds (perftest, librdmacm utils/examples, etc).
> > Generally, no, because various upstreams often do things that violate the
> > packaging rules for a given distro. Upstream specs are occasionally used
> > for reference bringing up a new package, but at least for Red Hat
> > and
>
> Well, that is exactly where we are right now, bringing up a new
> (complex) package.
I think the only really complex part is splitting it into sub-packages
correctly, which is mostly getting %files lists, Provides and Obsoletes
right, from the rpm perspective.
> Would you help making a spec file that is close to what you
> could use in the distro? I don't really care if it is stored in the
> package or stored inside RH, but we need to get one made.
Sure. It would probably be something to route through Fedora first though,
and I don't own all the packages this would encompass in Fedora, but could
certainly round a few people up and help out.
> > > Eg I think it was a dis-service to other distros not to update the
> > > reference verbs spec file with the libnl dependency. I wonder how many
> > > downstreams noticed this change and are still building verbs properly?
> >
> > Add the dependency to the build infra, and problem solved for rpm, deb,
> > whatever other packaging system. Updating the spec only helps rpm-based
> > distros, maybe, if they use the spec (which RH/Fedora doesn't).
>
> The build infra has an optional requirement for libnl3, and other
> things.
>
> I don't know why we did that, maybe it should have been mandatory, but
> the point remains, it is a subtle change that is easy to miss
> downstream. Presumably downstream folks review changes to the tarball
> including the reference spec file before packaging a new version?
Downstream folks should be reviewing release notes at the very least, and
preferably, upstream source code management commit logs, to have a clue
what they're packaging up. I'm sure not all do though.
--
Jarod Wilson
jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160826154206.GK1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-26 22:27 ` Jason Gunthorpe
[not found] ` <20160826222725.GA8553-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-06 19:26 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-26 22:27 UTC (permalink / raw)
To: Jarod Wilson
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Fri, Aug 26, 2016 at 11:42:06AM -0400, Jarod Wilson wrote:
> > Would you help making a spec file that is close to what you
> > could use in the distro? I don't really care if it is stored in the
> > package or stored inside RH, but we need to get one made.
>
> Sure. It would probably be something to route through Fedora first though,
> and I don't own all the packages this would encompass in Fedora, but could
> certainly round a few people up and help out.
Sounds good, here are my thoughts let me know what you think:
1) Compiler flags/etc. I haven't audited all the CentOS rpms, but at
least verbs overrides the compiler flag to set -fno-strict-aliasing
Upstream should be distributing the package in a way that works, so
downstream should not need do this. We need to decide if we want/need to
force no-strict-aliasing or not, or use some kind of compiler
test or whatever.
2) Static libraries. Do we want to continue to provide these? Looking
at it, I'm skeptical that libibverbs works at all as a static, does
anyone know? Particularly, how does it work? Should we get rid of
it or do more work to try and make it work sanely. (eg a
libibverbs.a that includes all the providers or something)
3) Version numbers. What version numbers do we give to the sub
packages? I guess this is very distro specific.
4) Package split. I'm suggesting
libibcm1 -devel -static
libibumad3 -devel -static
libibverbs1 -devel -static
librdmacm1 -devel -static
rdma-utils (all the other random binaries and stuff)
ibverbs-plugins (all the providers)
So we would get rid of the individual packages for the providers.
There would be no -devel for the providers and the static providers
would be bundled with libibverbs1-static
IMHO this is more inline with common distro practice for packaging
plugins. (most providers are about 20k-30k)
I don't want to dictate what distros should do, but this is best
done with support from the build system upstream, so some guidance
on what to do is needed to finish the cmake stuff. (see #6)
5) Valgrind - I've noticed CentOS forces valgrind on, and Debian
leaves it as the upstream default (off)
IMHO Upstream should shift to use valgrind by default if available
and encourage all downstreams to compile it with valgrind headers
present.
6) Actually splitting the file list. cmake has a INSTALL COMPONENT
facility to help with this, but it needs to be setup upstream.
Other than the include files and man pages this is straightforward
to do from the spec file
7) NDEBUG - As upstream do we want this set or left unset for a
release build. It eliminates all asserts and a few other things.
I'm not sure what is being done today, but the %cmake rpmbuild
default forces it on. (IMHO, upstream should decide this, not
downstream?)
8) COPYING file and other doc stuff. There are 4 different licenses
being used in the source. Everything is GPLv2 however. I think this
only impacts the providers.
9) libtool .la files. I preserved them, but if distros don't want them
I'd love to ditch them.
I'd like to get thing in a state where it is not painful for the
distros to transition - to ease things along.
My approach has been to faithfully preserve exactly what we do today,
and the list above is basicly my list of things that seem like they
need attention.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160825164753.GB20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-27 2:22 ` Doug Ledford
0 siblings, 0 replies; 174+ messages in thread
From: Doug Ledford @ 2016-08-27 2:22 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 890 bytes --]
On 8/25/2016 12:47 PM, Jason Gunthorpe wrote:
> On Thu, Aug 25, 2016 at 10:22:06AM -0400, Doug Ledford wrote:
>
>> Also, patchworks dropped all of the patches that were pure deletes.
>> Seems if there isn't some sort of patch to go along with the git delete
>> or chmod commands, it doesn't think it's a real patch.
>
> Hmm, is this a problem?
No, not a problem. Just an observation.
> I don't expect patchworks will be useful for
> the initial repository setup, as the special merge commit
> (e4a0ff72cfd8) cannot be sent as a patch, and all patches are on top
> of that.
>
> It would be easiest to pull from my github with a signed tag or
> something. This is why I elided the content of the deletes for
> readability (there is 54kloc deleted)
>
> Jason
>
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160826222725.GA8553-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-27 3:00 ` Doug Ledford
[not found] ` <5421f173-384d-faef-0eab-518db6dad0e5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-08-27 3:00 UTC (permalink / raw)
To: Jason Gunthorpe, Jarod Wilson
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 7517 bytes --]
On 8/26/2016 6:27 PM, Jason Gunthorpe wrote:
> On Fri, Aug 26, 2016 at 11:42:06AM -0400, Jarod Wilson wrote:
>
>>> Would you help making a spec file that is close to what you
>>> could use in the distro? I don't really care if it is stored in the
>>> package or stored inside RH, but we need to get one made.
>>
>> Sure. It would probably be something to route through Fedora first though,
>> and I don't own all the packages this would encompass in Fedora, but could
>> certainly round a few people up and help out.
>
> Sounds good, here are my thoughts let me know what you think:
>
> 1) Compiler flags/etc. I haven't audited all the CentOS rpms, but at
> least verbs overrides the compiler flag to set -fno-strict-aliasing
> Upstream should be distributing the package in a way that works, so
> downstream should not need do this. We need to decide if we want/need to
> force no-strict-aliasing or not, or use some kind of compiler
> test or whatever.
The most recent upstream libibverbs includes -fno-strict-aliasing now so
it can be dropped from the extra stuff in the Fedora spec file.
> 2) Static libraries. Do we want to continue to provide these? Looking
> at it, I'm skeptical that libibverbs works at all as a static, does
> anyone know? Particularly, how does it work? Should we get rid of
> it or do more work to try and make it work sanely. (eg a
> libibverbs.a that includes all the providers or something)
I'm ready to drop static libraries.
> 3) Version numbers. What version numbers do we give to the sub
> packages? I guess this is very distro specific.
You can not give different versions to sub-packages. Or, allow me to be
more precise: You can't use the Version: tag on sub-packages, it resets
the version of the entire package overall when you do. The last
Version: tag in the spec file ends up being the version applied to
everything. This impacts the %{version} macro usage in the spec file.
The only way to put versions on sub-packages is to make it part of the
sub-package's name.
But, really, once the whole schmeal is packaged together, you can't
distribute just an update to a driver, and you can't build just that
updated driver, so I would recommend we just package it all up in the
primary package.
For instance, in order to make certain things work well with the split
package setup, I had to use a fake pseudo require/provide pair in the
drivers and in libibverbs so that installing libibverbs would
automatically pull in the driver libraries too. If we just package the
driver libraries with the libibverbs library, that's all solved.
> 4) Package split. I'm suggesting
> libibcm1 -devel -static
> libibumad3 -devel -static
> libibverbs1 -devel -static
> librdmacm1 -devel -static
> rdma-utils (all the other random binaries and stuff)
> ibverbs-plugins (all the providers)
I've done this sort of package split in a single spec file. Once. I
undid it and never went back. I don't suggest going down this road.
Lots of things in spec files that are supposed to "just work" break when
you do this. The %{version} macro I mentioned above is just one of them.
If you instead do things as multiple spec files, then that would work.
It would be a little funky in terms of our build system to have multiple
packages that use the same source tarball, but it would work.
Essentially, our internal packages are defined on a per spec file basis,
so with multiple spec files, we would be forced to have multiple
distinct package in every way except that they use the same tarball. It
creates some interesting convolutions to think about how upstream
consolidates and we de-consolidate it right back to what it was ;-)
> So we would get rid of the individual packages for the providers.
> There would be no -devel for the providers and the static providers
> would be bundled with libibverbs1-static
The providers just need to be with the base libibverbs library. One
doesn't work without the other, the separation serves no purpose.
> IMHO this is more inline with common distro practice for packaging
> plugins. (most providers are about 20k-30k)
Normally I agree...when you have separate plugins and you only install
the ones you need. But, we only have a few drivers and installing just
the ones you need is more hassle than it's worth.
> I don't want to dictate what distros should do, but this is best
> done with support from the build system upstream, so some guidance
> on what to do is needed to finish the cmake stuff. (see #6)
I'm inclined to wrap it all up into a single package. librdmacm,
libibcm, libibumad, libibverbs, providers, all of it. I would also be
inclined to contribute the rdma scripts we have as part of the package
too. I think some of them can use some cleanups if they are going to
become an upstream item instead of a RH specific item, but otherwise
they work well. If I did that, I would also welcome appropriate similar
scripts for OSes that use different tools than RH OSes.
> 5) Valgrind - I've noticed CentOS forces valgrind on, and Debian
> leaves it as the upstream default (off)
> IMHO Upstream should shift to use valgrind by default if available
> and encourage all downstreams to compile it with valgrind headers
> present.
Agree. Changing the default on this when present is good.
> 6) Actually splitting the file list. cmake has a INSTALL COMPONENT
> facility to help with this, but it needs to be setup upstream.
> Other than the include files and man pages this is straightforward
> to do from the spec file
Not an issue if we package it all up together.
> 7) NDEBUG - As upstream do we want this set or left unset for a
> release build. It eliminates all asserts and a few other things.
> I'm not sure what is being done today, but the %cmake rpmbuild
> default forces it on. (IMHO, upstream should decide this, not
> downstream?)
I think I would set this. But I'm flexible. Basically, I know end
users want Valgrind. We've had multiple requests to enable it. They
don't want to install custom packages to get Valgrind support. But they
need Valgrind to help with debugging their own applications. So here,
if the NDEBUG being set turns off asserts for internal operations, then
we can set it. If it turns off asserts for user provided data or user
usage, then we probably ought to leave the asserts enabled. It all
boils down to whether or not the code eliminated and cycles saved are
internal debugging or a debugging aid for the end user's application.
If it helps them, it needs to stay enabled. If it verifies our own
operation, it doesn't.
> 8) COPYING file and other doc stuff. There are 4 different licenses
> being used in the source. Everything is GPLv2 however. I think this
> only impacts the providers.
> 9) libtool .la files. I preserved them, but if distros don't want them
> I'd love to ditch them.
Drop them.
> I'd like to get thing in a state where it is not painful for the
> distros to transition - to ease things along.
>
> My approach has been to faithfully preserve exactly what we do today,
> and the list above is basicly my list of things that seem like they
> need attention.
>
> Jason
>
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160825201306.GA5421-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-25 20:32 ` Steve Wise
2016-08-26 15:42 ` Jarod Wilson
@ 2016-08-27 3:17 ` Doug Ledford
[not found] ` <8ef70f6c-e26d-191d-9a9a-2e0bf47fb227-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2 siblings, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-08-27 3:17 UTC (permalink / raw)
To: Jason Gunthorpe, Jarod Wilson
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 3484 bytes --]
On 8/25/2016 4:13 PM, Jason Gunthorpe wrote:
>>> Are you saying we don't need a specfile in upstream?
>>
>> Distros certainly don't require it.
>
> I know that, my question is poised to the larger developer community
> who need to build test and deploy this stuff as not-a-distro.
Developers like to do things that driver packagers nuts ;-) For the
larger developer community, a decent set of default options for make
install in the repo itself is the main thing I think.
>>> How does upstream
>>> test the build infrastructure?
>>
>> ./configure, make, make install (or cmake/ninja/whatever)
>
> rpmbuild does stuff that needs to be checked out and validated by
> upstream at least occasionally, or packaging becomes too hard for the
> downstream because of broken build infra.
Given that rpmbuild is basically nothing more than a scripted build
session, as long as the make/cmake system works well, so will rpmbuild.
The main things that cause problems for distros when upstream does it
are things like using rpath to search alternate library locations. It
makes sense to a developer. She can have multiple installed copies of
the code and test different versions this way. For a distro though,
that's a major security issue as rpath searches by a distro installed
library can be exploited by black hats behind the user's back. So we
forcefully rip those out. Those are the sorts of things that are more
likely to crop up. But, as Jarod mentioned, we don't need to worry
about this too much. If something breaks, the distros will speak up.
> We've never been able to run the rdma stack from the build trees,
It's possible...you just have to do every step in the right order ;-) I
had a spreadsheet that I tracked packages, versions, build states,
install states, and dependencies. Made things a lot easier.
But I get your point.
> Would you help making a spec file that is close to what you
> could use in the distro? I don't really care if it is stored in the
> package or stored inside RH, but we need to get one made.
I have no doubt that we have plenty of spec file expertise on hand to
make a reasonable starting spec file for the repo. We'll need someone
else's help though for the non-rpm stuff.
> The build infra has an optional requirement for libnl3, and other
> things.
>
> I don't know why we did that, maybe it should have been mandatory, but
> the point remains, it is a subtle change that is easy to miss
> downstream. Presumably downstream folks review changes to the tarball
> including the reference spec file before packaging a new version?
They should review things, but stuff can slip through the cracks. Since
libnl3/libnl is needed for RoCE, and it's possible to build libibverbs
as something useful for IB and ignore RoCE, the libnl3/libnl requirement
shouldn't be mandatory. However, in order to make it very explicit
since I suspect most people want RoCE support and might not realize they
are missing a build requirement for it to work, the tests in the
configure script could be changed to add a new feature "RoCE Support
(default: yes)" and make the libnl3/libnl test be part of the RoCE
support, and if it isn't present, fail. Then people have to turn off
RoCE to build it without libnl3/libnl. That would be more effective of
a configure setup I think.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160825173916.GC20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-25 19:52 ` Jarod Wilson
@ 2016-08-27 3:34 ` Doug Ledford
1 sibling, 0 replies; 174+ messages in thread
From: Doug Ledford @ 2016-08-27 3:34 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 3116 bytes --]
On 8/25/2016 1:39 PM, Jason Gunthorpe wrote:
> On Thu, Aug 25, 2016 at 10:20:15AM -0400, Doug Ledford wrote:
>> On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
>>> On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
>>>
>>>> The full install to / is still a small TODO, it is part and parcel
>>>> with doing the packaging, in my mind.
>>>
>>> I just pushed a basic starting point rpm spec file, it still needs to
>>> be split into multiple subpackages, but it is installable with all the
>>> usual paths.
>>
>> You can do that, but I routinely tell upstream maintainers that we don't
>> touch their spec files. Every distro modifies the spec file so heavily
>> for their own custom installation that it just doesn't make much sense
>> to worry about it at the upstream level. Build one that can be used
>> when running rpmbuild -ta and that's all you need.
>
> I'm not sure I understand your comment.
>
> Are you saying we don't need a specfile in upstream?
I would include a spec file, it just need not be complex. So much of
what goes into one is distro specific, that there is a directly
proportional relationship between the complexity of the provided spec
file and chances that it will actually not be useful on anything other
than the one OS it was written on.
> How does upstream
> test the build infrastructure?
The downstream distros are really on the hook for that. Making sure the
make/cmake build works well is our main goal. The spec files and other
packaging files are templates, nothing more than that really.
> Are you saying the simple one .rpm is all we need?
Yep.
> Is that really
> useful to developers if it clashes with the distro packaging?
Yes. It's likely that no matter what we do, there will be differences
between how distro package things up and how we do. The developer will
need to manually uninstall the distro packages and then install the
package we provide.
> How do
> we test the build system parts that help the package splitting?
I wouldn't even go there :-)
> Isn't it easier for downstream to have recommended packaging to
> reference?
It is. But they don't always follow it regardless.
> Eg I think it was a dis-service to other distros not to update the
> reference verbs spec file with the libnl dependency. I wonder how many
> downstreams noticed this change and are still building verbs properly?
We do. But I was involved with the patches for the support and I was
still in charge of our packages at the time, so I knew. But even if we
had updated the spec file in the tarball, it wouldn't have mattered.
Whenever we import a new package, part of the import is to create our
own spec file. If there is a template, we might start from there, but
we essentially fork it immediately. We have to in order to maintain our
own spec %changelog. So changes to the template spec in the tarball
likely would have been missed just like the change to the configure script.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <5421f173-384d-faef-0eab-518db6dad0e5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-27 3:50 ` Jason Gunthorpe
2016-08-30 1:27 ` Jarod Wilson
1 sibling, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-27 3:50 UTC (permalink / raw)
To: Doug Ledford
Cc: Jarod Wilson, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Fri, Aug 26, 2016 at 11:00:22PM -0400, Doug Ledford wrote:
> The most recent upstream libibverbs includes -fno-strict-aliasing
> now so it can be dropped from the extra stuff in the Fedora spec
> file.
Looking at strict-aliasing is the last build issue, I'd like to
minimize the places we turn it on, so if we have been shipping
libraries that never needed it I don't want to blanket enable
it. Ideally we could run with -fstrict-aliasing, but I realize how
hard that can be..
Do you know there are confirmed bugs without -fno-strict-aliasing?
> 2) Static libraries. Do we want to continue to provide these?
> I'm ready to drop static libraries.
Great.
> > 3) Version numbers. What version numbers do we give to the sub
> > packages? I guess this is very distro specific.
>
> You can not give different versions to sub-packages. Or, allow me to be
> more precise: You can't use the Version: tag on sub-packages, it
> resets
Okay, I should also clarify that when putting this all together I need
to consider Debian as well. I'm happy if RH wants to just use a jumbo
RPM, but that doesn't match Debian Policy regarding shared libraries
[my suggestions were informed by Debian Policy].
So I may look at deb packaging to guide the cmake install components
then, and try and get someone from the Debian community involved. I
started with RPM because that seems to be what most of our developers
use.
> > I don't want to dictate what distros should do, but this is best
> > done with support from the build system upstream, so some guidance
> > on what to do is needed to finish the cmake stuff. (see #6)
>
> I'm inclined to wrap it all up into a single package. librdmacm,
> libibcm, libibumad, libibverbs, providers, all of it.
Okay, so just simple rdma-libs, rdma-utils, rdma-libs-devel works for
you? Nothing more to do then.
> I would also be inclined to contribute the rdma scripts we have as
> part of the package too. I think some of them can use some cleanups
> if they are going to become an upstream item instead of a RH
> specific item, but otherwise they work well. If I did that, I would
> also welcome appropriate similar scripts for OSes that use different
> tools than RH OSes.
This sounds like a good idea.
>> 5) Valgrind - I've noticed CentOS forces valgrind on, and Debian
> Agree. Changing the default on this when present is good.
Will do.
> > 7) NDEBUG - As upstream do we want this set or left unset for a
> > release build. It eliminates all asserts and a few other things.
> > I'm not sure what is being done today, but the %cmake rpmbuild
> > default forces it on. (IMHO, upstream should decide this, not
> > downstream?)
>
> I think I would set this. But I'm flexible. Basically, I know end
> users want Valgrind. We've had multiple requests to enable it.
> They
Okay, any thoughts on when assert should be enabled then? It is
useless to code it if we just compile it out in all builds.
Maybe non-packaging builds can default to leave assert in or
something?
> > 9) libtool .la files. I preserved them, but if distros don't want them
> > I'd love to ditch them.
>
> Drop them.
Yay, I think debian agrees.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <8ef70f6c-e26d-191d-9a9a-2e0bf47fb227-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-08-27 5:21 ` Jason Gunthorpe
2016-08-28 13:28 ` Leon Romanovsky
1 sibling, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-27 5:21 UTC (permalink / raw)
To: Doug Ledford
Cc: Jarod Wilson, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Fri, Aug 26, 2016 at 11:17:52PM -0400, Doug Ledford wrote:
> > rpmbuild does stuff that needs to be checked out and validated by
> > upstream at least occasionally, or packaging becomes too hard for the
> > downstream because of broken build infra.
>
> Given that rpmbuild is basically nothing more than a scripted build
> session, as long as the make/cmake system works well, so will
> rpmbuild.
Well, the thing that cases pain is the %configure and %cmake macros
that rpmbuild provides, and sorting out all the various distro-specific
install paths.
eg I ran into this bug with %cmake while testing
(see https://bugzilla.redhat.com/show_bug.cgi?id=1301720)
and had to deal with it in both the spec file and the build scripts.
> The main things that cause problems for distros when upstream does it
> are things like using rpath to search alternate library locations.
> It
rpath is sorted automatically. %cmake takes care of it.
Be aware that rpath will still be set in the build output, just
stripped during 'make install'.
> > We've never been able to run the rdma stack from the build trees,
>
> It's possible...you just have to do every step in the right order ;-) I
> had a spreadsheet that I tracked packages, versions, build states,
> install states, and dependencies. Made things a lot easier.
Yes, I've done that too, but the hardwired load path for the .driver
files is still a difficult problem.
I have an approach in mind to fix this too.
> shouldn't be mandatory. However, in order to make it very explicit
> since I suspect most people want RoCE support and might not realize they
> are missing a build requirement for it to work, the tests in the
> configure script could be changed to add a new feature "RoCE Support
> (default: yes)" and make the libnl3/libnl test be part of the RoCE
> support, and if it isn't present, fail. Then people have to turn off
> RoCE to build it without libnl3/libnl. That would be more effective of
> a configure setup I think.
Yes, I agree. This is straightforward to do as well, I'll look at it.
Also, do you know why we have the libnl1 fallback support? I couldn't
figure out what distro needed that.
BTW, I've basically de-supported any distro that doesn't have O_CLOEXEC
and related, which probably includes anything that needed libnl1. We
can probably remove libnl1 someday too.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <8ef70f6c-e26d-191d-9a9a-2e0bf47fb227-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-27 5:21 ` Jason Gunthorpe
@ 2016-08-28 13:28 ` Leon Romanovsky
[not found] ` <20160828132804.GN594-2ukJVAZIZ/Y@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-08-28 13:28 UTC (permalink / raw)
To: Doug Ledford
Cc: Jason Gunthorpe, Jarod Wilson, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On Fri, Aug 26, 2016 at 11:17:52PM -0400, Doug Ledford wrote:
> On 8/25/2016 4:13 PM, Jason Gunthorpe wrote:
> > We've never been able to run the rdma stack from the build trees,
>
> It's possible...you just have to do every step in the right order ;-) I
> had a spreadsheet that I tracked packages, versions, build states,
> install states, and dependencies. Made things a lot easier.
>
> But I get your point.
>
Sorry, but I missed your point. On my development machine, I'm
running all relevant RDMA stack directly from their git trees
without any excel file. It worked flawlessly without any
obstacles, did I do anything wrong?
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <cabbd0a7-0918-a8dd-d1e5-0b079f0c4604-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-25 14:22 ` Doug Ledford
2016-08-25 17:39 ` Jason Gunthorpe
@ 2016-08-28 16:14 ` Yishai Hadas
[not found] ` <c84de2a5-6526-c0a6-6535-519add3fbabb-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2 siblings, 1 reply; 174+ messages in thread
From: Yishai Hadas @ 2016-08-28 16:14 UTC (permalink / raw)
To: Doug Ledford
Cc: Jason Gunthorpe, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
Majd Dibbiny, liranl-VPRAkNaXOzVWk0Htik3J/w,
talal-VPRAkNaXOzVWk0Htik3J/w, yarong-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
On 8/25/2016 5:20 PM, Doug Ledford wrote:
> On 8/23/2016 2:54 PM, Jason Gunthorpe wrote:
>> On Mon, Aug 22, 2016 at 03:43:52PM -0600, Jason Gunthorpe wrote:
>>
>>> The full install to / is still a small TODO, it is part and parcel
>>> with doing the packaging, in my mind.
>>
>> I just pushed a basic starting point rpm spec file, it still needs to
>> be split into multiple subpackages, but it is installable with all the
>> usual paths.
>
> You can do that, but I routinely tell upstream maintainers that we don't
> touch their spec files. Every distro modifies the spec file so heavily
> for their own custom installation that it just doesn't make much sense
> to worry about it at the upstream level. Build one that can be used
> when running rpmbuild -ta and that's all you need.
>
It's not just an issue of a vendor specific spec file that should stay
unchanged.
Today each vendor manages its code and is not exposed to bugs/issues in
other vendors. Moving to a consolidate rpm might cause that any bug fix
in one component will force a new release of all other stuff without any
real reason. Introducing such a dependency might even delay/block a
release without any justification.
I believe that we agree that each maintainer should be independent to
review/accept relevant code to his component and make sure that his code
is fully tested and ready for a release in any given time.
Put all code in one big umbrella letting only one person to accept code
is not a good idea which might slow the process of accepting new code
and features.
We can't expect one person to know all vendor's details and have time to
manage all of that.
In addition, need to consider that there are few distros which have
releases in different times, the flexibility to take a specific
component based on its readiness and importance is a vital
point that must be saved as done today.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <c84de2a5-6526-c0a6-6535-519add3fbabb-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2016-08-28 18:27 ` Jason Gunthorpe
[not found] ` <20160828182715.GA12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-28 18:27 UTC (permalink / raw)
To: Yishai Hadas
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
Majd Dibbiny, liranl-VPRAkNaXOzVWk0Htik3J/w,
talal-VPRAkNaXOzVWk0Htik3J/w, yarong-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
On Sun, Aug 28, 2016 at 07:14:31PM +0300, Yishai Hadas wrote:
> Today each vendor manages its code and is not exposed to bugs/issues in
> other vendors. Moving to a consolidate rpm might cause that any bug fix in
> one component will force a new release of all other stuff without any real
> reason. Introducing such a dependency might even delay/block a release
> without any justification.
We already went over this with Steve, and the consensus was this isn't
a practical problem.
Please read the thread from here:
https://www.spinics.net/lists/linux-rdma/msg37813.html
There is some excellent information on how the distribution processes
work and general support from the community on this integration.
The basic summary is that this consolidation allows the
already-existing per-distro coordiation of all the libraries and the
providers to happen in the open and be shared by all the downstream
consumers.
Things would be more like the kernel flow where the distros will
monitor one place for bug fixes to back port (rdma-plumbing) and
vendors will still work with the distro to get their specific patches
backported.
Remember, by the time we get to the provider level there are already
often dependencies in the kernel and libibverbs that need to be met by
the distro, so it has rarely been the case of 'just grab my libprovider and
you are good'
The few case like that are also trivially cherry-pickable patches.
This makes things easier for all the downstream users by providing a
single source reference, and makes it easier for developers beacuse we
can update all providers in one pass with one pull request.
The other thing to bear in mind is that most of the code is
dead. Other than a few providers there simply is no churn. All the
work is keeping everything up to date and still compiling on modern
distros/arches/etc.
I'm expecting that the whole thing will remain continuously releasable
exactly because it is largely all dead code. If a vendor pushes a bug
into their provider then they are going to get burned, not other vendors.
However, we face the ioctl UAPI conversion in our future, and tackling
that across 15 different dead git trees with MIA maintainers is simply
too hard. I view this work as a necessary precondition for the UAPI
fixup.
> I believe that we agree that each maintainer should be independent to
> review/accept relevant code to his component and make sure that his code is
> fully tested and ready for a release in any given time.
The model is exactly the same as the kernel, which is proven to work,
and does expect that all patches are release ready.
Sean has proven this model works with libfabric and has shown
benefits of building community infrastructure.
> Put all code in one big umbrella letting only one person to accept code is
> not a good idea which might slow the process of accepting new code and
> features.
This is already basically the case, you need to wait for Doug to take
any libibverbs changes before you can push any provider feature
change.
If this really concerns you then propose a maintainer team scheme -
eg hosting this on github would allow for that.
> In addition, need to consider that there are few distros which have releases
> in different times, the flexibility to take a specific component based on
> its readiness and importance is a vital
> point that must be saved as done today.
Again, it doesn't matter. The distros will take from upstream whenever
they are ready and upstream is 'continuously releasable'. This way the
distros can get everything and not have to hunt down 15 different git
trees randomly sprinkled across the internet
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160828132804.GN594-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-08-28 18:36 ` Jason Gunthorpe
[not found] ` <20160828183627.GC12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-28 18:36 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jarod Wilson, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Sun, Aug 28, 2016 at 04:28:04PM +0300, Leon Romanovsky wrote:
> On Fri, Aug 26, 2016 at 11:17:52PM -0400, Doug Ledford wrote:
> > On 8/25/2016 4:13 PM, Jason Gunthorpe wrote:
> > > We've never been able to run the rdma stack from the build trees,
> >
> > It's possible...you just have to do every step in the right order ;-) I
> > had a spreadsheet that I tracked packages, versions, build states,
> > install states, and dependencies. Made things a lot easier.
> >
> > But I get your point.
> >
>
> Sorry, but I missed your point. On my development machine, I'm
> running all relevant RDMA stack directly from their git trees
> without any excel file. It worked flawlessly without any
> obstacles, did I do anything wrong?
Maybe, because it is fairly hard to do correctly.
How do you make sure that eg librdmacm or a provider is built against
the git checkout of verbs, headers, shlib and all?
How do you rebuild the right trees if a change is made to verbs?
How do you have verbs load the provider driver from the git directory build?
When I said 'from the build trees' I mean without a 'make install',
just run 'build/bin/ibvdev_info' for instance and it guarenteed uses
the build products exclusively, including all the libraries and
providers.
Or set LD_LIBRARY_PATH=`pwd`/build/lib and have everything
use the new build.
This is the goal, and the consolidated repo can do everything except
the providers right now.
Doug is also adressing a larger issue with packaging and getting
everything to build correctly as the distro - he talked about it here:
https://www.spinics.net/lists/linux-rdma/msg37855.html
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160828183627.GC12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-29 6:29 ` Leon Romanovsky
[not found] ` <20160829062918.GR594-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-08-29 6:29 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, Jarod Wilson, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]
On Sun, Aug 28, 2016 at 12:36:27PM -0600, Jason Gunthorpe wrote:
> On Sun, Aug 28, 2016 at 04:28:04PM +0300, Leon Romanovsky wrote:
> > On Fri, Aug 26, 2016 at 11:17:52PM -0400, Doug Ledford wrote:
> > > On 8/25/2016 4:13 PM, Jason Gunthorpe wrote:
> > > > We've never been able to run the rdma stack from the build trees,
> > >
> > > It's possible...you just have to do every step in the right order ;-) I
> > > had a spreadsheet that I tracked packages, versions, build states,
> > > install states, and dependencies. Made things a lot easier.
> > >
> > > But I get your point.
> > >
> >
> > Sorry, but I missed your point. On my development machine, I'm
> > running all relevant RDMA stack directly from their git trees
> > without any excel file. It worked flawlessly without any
> > obstacles, did I do anything wrong?
>
> Maybe, because it is fairly hard to do correctly.
>
> How do you make sure that eg librdmacm or a provider is built against
> the git checkout of verbs, headers, shlib and all?
>
> How do you rebuild the right trees if a change is made to verbs?
>
> How do you have verbs load the provider driver from the git directory build?
>
> When I said 'from the build trees' I mean without a 'make install',
> just run 'build/bin/ibvdev_info' for instance and it guarenteed uses
> the build products exclusively, including all the libraries and
> providers.
>
> Or set LD_LIBRARY_PATH=`pwd`/build/lib and have everything
> use the new build.
>
> This is the goal, and the consolidated repo can do everything except
> the providers right now.
I'm doing that by running number of one liners [1], it builds me
development setup in shared folder, so my base image is continuing
to be clean.
It is not final version, I didn't upload it yet.
Libraries:
@echo "Build libibverbs"
@cd $(LIBIBVERBS_SRC)/; ./autogen.sh; ./configure --prefix=$(KVM_SHARED) CFLAGS=-I$(KVM_SHARED)/include LDFLAGS=-L$(KVM_SHARED)/lib CPPFLAGS=-I$(KVM_SHARED)/include; $(MAKE); $(MAKE) install
@echo "Build libmlx5"
@cd $(LIBMLX5_SRC)/; ./autogen.sh; ./configure --prefix=$(KVM_SHARED) CFLAGS=-I$(KVM_SHARED)/include LDFLAGS=-L$(KVM_SHARED)/lib CPPFLAGS=-I$(KVM_SHARED)/include; $(MAKE); $(MAKE) install
Kernel headers:
@echo "Install kernel headers"
@make -C $(KERNEL_SRC) headers_install INSTALL_HDR_PATH=$(KVM_SHARED)
>
> Doug is also adressing a larger issue with packaging and getting
> everything to build correctly as the distro - he talked about it here:
>
> https://www.spinics.net/lists/linux-rdma/msg37855.html
I read that thread and think that it is related to unoptimized build
process of one distro who for any reason decided do not use repo tool
[2] for managing complex build dependencies between different git trees,
but used excel file and manual download of source tarballs.
We used such tool for our 100+ git trees project and it worked like a charm.
There is worth to invest time and revise internal process of releasing
RDMA stack in that specific distro and no need to invent new beast
(rdma-plumbers).
[1] https://github.com/rleon/dev-scripts/blob/master/Makefile#L89
[2] https://source.android.com/source/developing.html
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160828182715.GA12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-29 12:07 ` Yishai Hadas
[not found] ` <765b7e2d-51e0-98aa-60d1-26be35eb7a3d-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-08-29 14:39 ` Steve Wise
1 sibling, 1 reply; 174+ messages in thread
From: Yishai Hadas @ 2016-08-29 12:07 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
Majd Dibbiny, liranl-VPRAkNaXOzVWk0Htik3J/w,
talal-VPRAkNaXOzVWk0Htik3J/w, yarong-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
On 8/28/2016 9:27 PM, Jason Gunthorpe wrote:
> On Sun, Aug 28, 2016 at 07:14:31PM +0300, Yishai Hadas wrote:
>
>> Today each vendor manages its code and is not exposed to bugs/issues in
>> other vendors. Moving to a consolidate rpm might cause that any bug fix in
>> one component will force a new release of all other stuff without any real
>> reason. Introducing such a dependency might even delay/block a release
>> without any justification.
>
> We already went over this with Steve, and the consensus was this isn't
> a practical problem.
>
> Please read the thread from here:
>
> https://www.spinics.net/lists/linux-rdma/msg37813.html
Already read it, still issue is open, any major bug fix in one vendor
code might require a new package, comparing current situation that
components are self-contained.
> Remember, by the time we get to the provider level there are already
> often dependencies in the kernel and libibverbs that need to be met by
> the distro, so it has rarely been the case of 'just grab my libprovider and
> you are good'
Each commit today to libibverbs must maintain compatibility with other
vendors and can't break one of, I don't believe that this is going to be
changed by that model.
>> I believe that we agree that each maintainer should be independent to
>> review/accept relevant code to his component and make sure that his code is
>> fully tested and ready for a release in any given time.
>
> The model is exactly the same as the kernel, which is proven to work,
> and does expect that all patches are release ready.
The kernel is managed by pull requests to Linus from few maintainers, it
has a clear cycle of time frames for releases, etc.
Are you talking about same model that each maintainer will maintain his
GIT and upon known time-frames will ask the main maintainer (who ever
that will be) to take from their gits ? today the cycles in user space
for such a flow are not defined, moving to that model in user space
without a well defined process might be a very bad idea that will slow
the process of having things formally upstream.
>> Put all code in one big umbrella letting only one person to accept code is
>> not a good idea which might slow the process of accepting new code and
>> features.
>
> This is already basically the case, you need to wait for Doug to take
> any libibverbs changes before you can push any provider feature
> change.
This is incorrect, when Doug is taking into libibverbs, vendor code that
is ready can be taken immediately, the new approach might cause some
extra delays and slowness.
In addition, there are changes in a provider code that are not depend on
libibverbs, like bug fixes, internal enhancements, etc. No reason to
wait for a slot from Doug, changes can be taken when they are ready.
> If this really concerns you then propose a maintainer team scheme -
> eg hosting this on github would allow for that.
The maintaining issues as described above are not solved by some extra
github.
>> In addition, need to consider that there are few distros which have releases
>> in different times, the flexibility to take a specific component based on
>> its readiness and importance is a vital
>> point that must be saved as done today.
>
> Again, it doesn't matter. The distros will take from upstream whenever
> they are ready and upstream is 'continuously releasable'. This way the
> distros can get everything and not have to hunt down 15 different git
> trees randomly sprinkled across the internet
Every one can build a local GIT that points to remote upstream GITs and
pull latest code in one command.
We must save the development/acceptance process flexible and fast and
not put some extra barriers that may slow it in the way.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160828182715.GA12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-29 12:07 ` Yishai Hadas
@ 2016-08-29 14:39 ` Steve Wise
2016-08-29 16:19 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Steve Wise @ 2016-08-29 14:39 UTC (permalink / raw)
To: 'Jason Gunthorpe', 'Yishai Hadas'
Cc: 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w, leonro-VPRAkNaXOzVWk0Htik3J/w
>
> On Sun, Aug 28, 2016 at 07:14:31PM +0300, Yishai Hadas wrote:
>
> > Today each vendor manages its code and is not exposed to bugs/issues in
> > other vendors. Moving to a consolidate rpm might cause that any bug fix in
> > one component will force a new release of all other stuff without any real
> > reason. Introducing such a dependency might even delay/block a release
> > without any justification.
>
> We already went over this with Steve, and the consensus was this isn't
> a practical problem.
>
> Please read the thread from here:
>
> https://www.spinics.net/lists/linux-rdma/msg37813.html
>
> There is some excellent information on how the distribution processes
> work and general support from the community on this integration.
>
> The basic summary is that this consolidation allows the
> already-existing per-distro coordiation of all the libraries and the
> providers to happen in the open and be shared by all the downstream
> consumers.
>
> Things would be more like the kernel flow where the distros will
> monitor one place for bug fixes to back port (rdma-plumbing) and
> vendors will still work with the distro to get their specific patches
> backported.
>
> Remember, by the time we get to the provider level there are already
> often dependencies in the kernel and libibverbs that need to be met by
> the distro, so it has rarely been the case of 'just grab my libprovider and
> you are good'
>
> The few case like that are also trivially cherry-pickable patches.
>
> This makes things easier for all the downstream users by providing a
> single source reference, and makes it easier for developers beacuse we
> can update all providers in one pass with one pull request.
>
> The other thing to bear in mind is that most of the code is
> dead. Other than a few providers there simply is no churn. All the
> work is keeping everything up to date and still compiling on modern
> distros/arches/etc.
>
> I'm expecting that the whole thing will remain continuously releasable
> exactly because it is largely all dead code. If a vendor pushes a bug
> into their provider then they are going to get burned, not other vendors.
>
> However, we face the ioctl UAPI conversion in our future, and tackling
> that across 15 different dead git trees with MIA maintainers is simply
> too hard. I view this work as a necessary precondition for the UAPI
> fixup.
>
> > I believe that we agree that each maintainer should be independent to
> > review/accept relevant code to his component and make sure that his code is
> > fully tested and ready for a release in any given time.
>
> The model is exactly the same as the kernel, which is proven to work,
> and does expect that all patches are release ready.
>
> Sean has proven this model works with libfabric and has shown
> benefits of building community infrastructure.
>
> > Put all code in one big umbrella letting only one person to accept code is
> > not a good idea which might slow the process of accepting new code and
> > features.
>
> This is already basically the case, you need to wait for Doug to take
> any libibverbs changes before you can push any provider feature
> change.
>
> If this really concerns you then propose a maintainer team scheme -
> eg hosting this on github would allow for that.
>
> > In addition, need to consider that there are few distros which have releases
> > in different times, the flexibility to take a specific component based on
> > its readiness and importance is a vital
> > point that must be saved as done today.
>
> Again, it doesn't matter. The distros will take from upstream whenever
> they are ready and upstream is 'continuously releasable'. This way the
> distros can get everything and not have to hunt down 15 different git
> trees randomly sprinkled across the internet
>
Please walk us through this scenario: Vendor X has very important changes to
their provider lib that enables new a hw device. There is no dependency on any
other rdma-plumbing library. How will that new important enhancement get made
available to downstream distros in a timely manner?
Thanks,
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160829062918.GR594-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-08-29 16:00 ` Jason Gunthorpe
[not found] ` <20160829160009.GA23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 18:51 ` Doug Ledford
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-29 16:00 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jarod Wilson, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Mon, Aug 29, 2016 at 09:29:18AM +0300, Leon Romanovsky wrote:
> I'm doing that by running number of one liners [1], it builds me
> development setup in shared folder, so my base image is continuing
> to be clean.
Yes, I've done this approach as well, I actually have a script some
place that kinda automates it. This is not nearly as easy to do as a
single tree inplace build, and requires some expertise to setup.
You'd be less happy if you scaled it to all our trees..
> > Doug is also adressing a larger issue with packaging and getting
> > everything to build correctly as the distro - he talked about it here:
> >
> > https://www.spinics.net/lists/linux-rdma/msg37855.html
>
> I read that thread and think that it is related to unoptimized build
> process of one distro who for any reason decided do not use repo tool
> [2] for managing complex build dependencies between different git trees,
> but used excel file and manual download of source tarballs.
Do not underestimate how hard a job the distro people have.
> RDMA stack in that specific distro and no need to invent new beast
> (rdma-plumbers).
Progress, Leon!
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-08-29 14:39 ` Steve Wise
@ 2016-08-29 16:19 ` Jason Gunthorpe
[not found] ` <20160829161902.GB23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-29 16:19 UTC (permalink / raw)
To: Steve Wise
Cc: 'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w, leonro-VPRAkNaXOzVWk0Htik3J/w
On Mon, Aug 29, 2016 at 09:39:01AM -0500, Steve Wise wrote:
> > Again, it doesn't matter. The distros will take from upstream whenever
> > they are ready and upstream is 'continuously releasable'. This way the
> > distros can get everything and not have to hunt down 15 different git
> > trees randomly sprinkled across the internet
>
> Please walk us through this scenario: Vendor X has very important changes to
> their provider lib that enables new a hw device. There is no dependency on any
> other rdma-plumbing library. How will that new important enhancement get made
> available to downstream distros in a timely manner?
Post the patch. Tag it with a Fixes: line. Doug/etc pick it
up. Distros notice the new commit on git, marked for backporting and
consider backporting it into their distro.
The vendor will still probably have to lobby the distros to include
the specific change quickly, that is no different of course. At least
now there is a better chance the non-lobbied distros will keep pace..
Same basic process as the kernel.
End-users observing the single tree can get the change very quickly by
grabbing the single git and building it to their distro's packages.
The state today is pretty sad. For example, libmlx4 is up to 1.2.1,
while the best I can get from Debian is 1.0.6.
In your specific case, you've kind of missed the large problem.
libcxgb4 isn't even packaged in Debian (or derived). A big swath of
Linux users don't even have your code available from their distro *at
all* - and that is a direct consequence of this mess we have made
upstream.
The distros are obviously not acceptably keeping pace with our
upstream mess. It looks like only Doug and RH are able to keep
up. IIRC John at SuSE just uses OFED (bleck) rather than sort this all
out by hand.
Further, we have another pending 2-3 upstream kernel drivers coming
and I have no idea where to find their userspace components..
We need to grow up and provide something sensible for our downstreams,
so our users can get the software easily..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <765b7e2d-51e0-98aa-60d1-26be35eb7a3d-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2016-08-29 16:34 ` Jason Gunthorpe
[not found] ` <20160829163453.GC23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-29 16:34 UTC (permalink / raw)
To: Yishai Hadas
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
Majd Dibbiny, liranl-VPRAkNaXOzVWk0Htik3J/w,
talal-VPRAkNaXOzVWk0Htik3J/w, yarong-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
On Mon, Aug 29, 2016 at 03:07:48PM +0300, Yishai Hadas wrote:
> >We already went over this with Steve, and the consensus was this isn't
> >a practical problem.
> >
> >Please read the thread from here:
> >
> >https://www.spinics.net/lists/linux-rdma/msg37813.html
>
> Already read it, still issue is open, any major bug fix in one vendor code
> might require a new package, comparing current situation that components are
> self-contained.
They are not self-contained. They have all sorts of inter-dependencies
between each other and the kernel. Going forward do not expect the
distros to just blindly take whatever tar ball you publish into their
stable releases. That was special situation for the 'Technology
Preview' stage in RHEL6.
Providing well described backportable patches and maybe even a
'stable' branch is far more in line with what the distros want from a
mature and stable upstream.
> >Remember, by the time we get to the provider level there are already
> >often dependencies in the kernel and libibverbs that need to be met by
> >the distro, so it has rarely been the case of 'just grab my libprovider and
> >you are good'
>
> Each commit today to libibverbs must maintain compatibility with other
> vendors and can't break one of, I don't believe that this is going to be
> changed by that model.
It is hard to say. I fully expect we will break all the providers when
we do the uAPI transition, anything else will likely be too hard. Hard
to know at this point.
> The kernel is managed by pull requests to Linus from few maintainers, it has
> a clear cycle of time frames for releases, etc.
But it also *doesn't matter*. The distros do not necessarily wait for
4.x to start looking at backportables fixes. They monitor patches
coming in and take them as they see fit independent of the release
cadence.
> Are you talking about same model that each maintainer will maintain his GIT
> and upon known time-frames will ask the main maintainer (who ever that will
> be) to take from their gits ? today the cycles in user space for such a flow
> are not defined, moving to that model in user space without a well defined
> process might be a very bad idea that will slow the process of having things
> formally upstream.
Right now I am just building the tree and making sure the technical
bits work. I think all the people on this CC list should work out a
process.
Remember, most of the code is dead, the maintainer is MIA or hasn't
accepted a patch in months or years.
mlx4/mlx5 is an notable exeption. You and Doug should work out a
reasonable appraoch. Maybe he takes your pulls directly, maybe you
have co-commit access on Github (the team approach), something else?
> >This is already basically the case, you need to wait for Doug to take
> >any libibverbs changes before you can push any provider feature
> >change.
>
> This is incorrect, when Doug is taking into libibverbs, vendor code that is
> ready can be taken immediately, the new approach might cause some extra
> delays and slowness.
I haven't seen you do that.
If you are pushing code into your provider that doesn't work with
upstream libibverbs then you will be blacklisted by the distros. Do
not do that.
> >If this really concerns you then propose a maintainer team scheme -
> >eg hosting this on github would allow for that.
>
> The maintaining issues as described above are not solved by some extra
> github.
Of course they are, you should familiarize yourself with how the team
features work on github.
> We must save the development/acceptance process flexible and fast and not
> put some extra barriers that may slow it in the way.
No, the main issue here is to clean up our releationship with the
distros and behave as a sensible and mature upstream.
I believe we can do that without a significant impact on the patch
flow.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160829163453.GC23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-29 20:03 ` Yishai Hadas
[not found] ` <aaf8d6ba-6dc2-51d9-b014-dcc10114079f-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Yishai Hadas @ 2016-08-29 20:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
Majd Dibbiny, liranl-VPRAkNaXOzVWk0Htik3J/w,
talal-VPRAkNaXOzVWk0Htik3J/w, yarong-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
On 8/29/2016 7:34 PM, Jason Gunthorpe wrote:
> On Mon, Aug 29, 2016 at 03:07:48PM +0300, Yishai Hadas wrote:
>
> They are not self-contained. They have all sorts of inter-dependencies
> between each other and the kernel.
The dependencies are around the interfaces with the kernel and with
applications, not in other parts. Using the extension mechanism a
provider can extend both APIs without breaking other.
Going forward do not expect the
> distros to just blindly take whatever tar ball you publish into their
> stable releases. That was special situation for the 'Technology
> Preview' stage in RHEL6.
>
No distro expects to take blindly and if it does it's bad.
AFAIK, there are testing and other actions done in in both distros and
providers sides to make sure that any package is ready for a release.
> Remember, most of the code is dead, the maintainer is MIA or hasn't
> accepted a patch in months or years.
Agree, that's why I think that such dead providers code shouldn't be put
and maintained with live providers, it doesn't make sense.
How many providers/libraries in this GIT are really active ?
> mlx4/mlx5 is an notable exeption. You and Doug should work out a
> reasonable appraoch. Maybe he takes your pulls directly, maybe you
> have co-commit access on Github (the team approach), something else?
We definitely need to close this point before going a head into any
solution that might block a fast progress of accepting/merging new code
of live/maintained projects as of libmlx4/5.
>>> This is already basically the case, you need to wait for Doug to take
>>> any libibverbs changes before you can push any provider feature
>>> change.
We should definitely find a way to escalate the review/acceptance of new
features in libibverbs, need to take it with Doug as well.
>> This is incorrect, when Doug is taking into libibverbs, vendor code that is
>> ready can be taken immediately, the new approach might cause some extra
>> delays and slowness.
>
> I haven't seen you do that.
What are you talking about ? see last feature of TSO as an example, it
was published in the list for both libibverbs and libmlx5, when Doug
accepted the libiberbs part just an hour later I merged the libmlx5 part
into its formal GIT at openfabrics and noted on that in the list.
Same was done for other features as of timestamping, rereg_mr, etc.
We must save this ability before going forward here.
> If you are pushing code into your provider that doesn't work with
> upstream libibverbs then you will be blacklisted by the distros. Do
> not do that.
Sure that we take *only* code that works with upstream libibverbs. Both
libmlx4 and libmlx5 are *always* in a ready state for a release with
latest libibverbs.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <aaf8d6ba-6dc2-51d9-b014-dcc10114079f-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2016-08-29 20:37 ` Jason Gunthorpe
[not found] ` <20160829203711.GC3201-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-29 20:37 UTC (permalink / raw)
To: Yishai Hadas
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
Majd Dibbiny, liranl-VPRAkNaXOzVWk0Htik3J/w,
talal-VPRAkNaXOzVWk0Htik3J/w, yarong-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
On Mon, Aug 29, 2016 at 11:03:45PM +0300, Yishai Hadas wrote:
> >Remember, most of the code is dead, the maintainer is MIA or hasn't
> >accepted a patch in months or years.
>
> Agree, that's why I think that such dead providers code shouldn't be put and
> maintained with live providers, it doesn't make sense.
> How many providers/libraries in this GIT are really active ?
What? That is backwards. The best way to carry 'finished' code is in a
live and active repository, otherwise it just tends to bitrot into
failure.
Having it be an active part of day-to-day developer work flows is the
best way to keep 'finished' code compiling and working over the long
run.
This is how the kernel flow has worked for many years and it largely
is proven to be a success.
For instance, with rdma-plumbing it would have been trivial for Steve
to at least compile test his ARM64 enablement across all providers.
It was easy for me to fix the pthread mislinking across all providers.
It will also be easy to do 'build and run in place'.
Let alone things like Covarity, Travis CI and other tooling that is
cumbersome to access across 15 different source trees.
> >mlx4/mlx5 is an notable exeption. You and Doug should work out a
> >reasonable appraoch. Maybe he takes your pulls directly, maybe you
> >have co-commit access on Github (the team approach), something else?
>
> We definitely need to close this point before going a head into any solution
> that might block a fast progress of accepting/merging new code of
> live/maintained projects as of libmlx4/5.
The obvious channel for something like your TSO example is the same as
the kernel, Doug takes the common code and the only implementation
(mlx5) together at the same time.
This is pretty much what we have been doing on the kernel side.
There is zero reason to delay the driver side once the verbs side is
OK.
I'm looking at the git commit activity on mlx4 and mlx5 and I honestly
don't see your concern, the commit rate is maybe 1 series every 3
months on mlx5 and even less on mlx4. Nothing here is so active that a
combination would be a significant negative, and by far the majority
of it is tied to verbs features anyhow.
> >>>This is already basically the case, you need to wait for Doug to take
> >>>any libibverbs changes before you can push any provider feature
> >>>change.
> >>This is incorrect, when Doug is taking into libibverbs, vendor code that is
> >>ready can be taken immediately, the new approach might cause some extra
> >>delays and slowness.
> >
> >I haven't seen you do that.
>
> What are you talking about ?
We are having troubles with English, apparently.
> Sure that we take *only* code that works with upstream libibverbs. Both
> libmlx4 and libmlx5 are *always* in a ready state for a release with latest
> libibverbs.
So nothing changes.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <5421f173-384d-faef-0eab-518db6dad0e5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-27 3:50 ` Jason Gunthorpe
@ 2016-08-30 1:27 ` Jarod Wilson
[not found] ` <20160830012738.GH6803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Jarod Wilson @ 2016-08-30 1:27 UTC (permalink / raw)
To: Doug Ledford
Cc: Jason Gunthorpe, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Fri, Aug 26, 2016 at 11:00:22PM -0400, Doug Ledford wrote:
> On 8/26/2016 6:27 PM, Jason Gunthorpe wrote:
...
> > 3) Version numbers. What version numbers do we give to the sub
> > packages? I guess this is very distro specific.
>
> You can not give different versions to sub-packages. Or, allow me to be
> more precise: You can't use the Version: tag on sub-packages, it resets
> the version of the entire package overall when you do. The last
> Version: tag in the spec file ends up being the version applied to
> everything. This impacts the %{version} macro usage in the spec file.
> The only way to put versions on sub-packages is to make it part of the
> sub-package's name.
I'm not so sure about that. Check out our linux-firmware package and
sub-packages. There are several firmwares with their own Version: tags in
their sub-package definitions, and the base linux-firmware package still
comes out of there with the intended original Version: from the top of the
spec. I suppose %{version} maybe does get stomped on, but the solution
I've seen used is to simply set an extra %global and use that where you
would have used %{version} in the spec.
That said, I tend to agree with what Doug is saying... If this is all one
big tree, then it's one big release, and should have one big consistent
version number, most likely. Otherwise, it's a massive headache and a bit
of a mess to maintain, package-wise, like he said.
--
Jarod Wilson
jarod-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160829160009.GA23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-30 5:43 ` Leon Romanovsky
[not found] ` <20160830054352.GI594-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-08-30 5:43 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, Jarod Wilson, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
On Mon, Aug 29, 2016 at 10:00:09AM -0600, Jason Gunthorpe wrote:
> On Mon, Aug 29, 2016 at 09:29:18AM +0300, Leon Romanovsky wrote:
>
> > I'm doing that by running number of one liners [1], it builds me
> > development setup in shared folder, so my base image is continuing
> > to be clean.
>
> Yes, I've done this approach as well, I actually have a script some
> place that kinda automates it. This is not nearly as easy to do as a
> single tree inplace build, and requires some expertise to setup.
>
> You'd be less happy if you scaled it to all our trees..
>
> > > Doug is also adressing a larger issue with packaging and getting
> > > everything to build correctly as the distro - he talked about it here:
> > >
> > > https://www.spinics.net/lists/linux-rdma/msg37855.html
> >
> > I read that thread and think that it is related to unoptimized build
> > process of one distro who for any reason decided do not use repo tool
> > [2] for managing complex build dependencies between different git trees,
> > but used excel file and manual download of source tarballs.
>
> Do not underestimate how hard a job the distro people have.
Everyone works hard, especially they, and the question is do the distro
people want to revise their process. The change of upstream process to
suit their needs is a nice solution, but it needs to be beneficial to
everyone. Current proposal is not good to vendors, who are responsible
for upstreaming their work.
>
> > RDMA stack in that specific distro and no need to invent new beast
> > (rdma-plumbers).
>
> Progress, Leon!
I disagree that removing old, unsupported libraries from the graves is
called progress.
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160829161902.GB23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-30 6:08 ` Leon Romanovsky
[not found] ` <20160830060842.GJ594-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-08-30 6:08 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, 'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]
On Mon, Aug 29, 2016 at 10:19:02AM -0600, Jason Gunthorpe wrote:
> On Mon, Aug 29, 2016 at 09:39:01AM -0500, Steve Wise wrote:
>
> > > Again, it doesn't matter. The distros will take from upstream whenever
> > > they are ready and upstream is 'continuously releasable'. This way the
> > > distros can get everything and not have to hunt down 15 different git
> > > trees randomly sprinkled across the internet
> >
> > Please walk us through this scenario: Vendor X has very important changes to
> > their provider lib that enables new a hw device. There is no dependency on any
> > other rdma-plumbing library. How will that new important enhancement get made
> > available to downstream distros in a timely manner?
>
> Post the patch. Tag it with a Fixes: line. Doug/etc pick it
> up. Distros notice the new commit on git, marked for backporting and
> consider backporting it into their distro.
Doug is a busy person and there is a limit on how fast he can handle it.
He is already buried under his internal and external responsibilities.
Placing him responsible for vendors code will add extra step,
extra complexity to the chain and will hurt kernel/libibverbs flows.
In addition, Steve's change is not a fix, but new functionality.
>
> The vendor will still probably have to lobby the distros to include
> the specific change quickly, that is no different of course. At least
> now there is a better chance the non-lobbied distros will keep pace..
>
> Same basic process as the kernel.
>
> End-users observing the single tree can get the change very quickly by
> grabbing the single git and building it to their distro's packages.
>
> The state today is pretty sad. For example, libmlx4 is up to 1.2.1,
> while the best I can get from Debian is 1.0.6.
The point is taken.
>
> In your specific case, you've kind of missed the large problem.
> libcxgb4 isn't even packaged in Debian (or derived). A big swath of
> Linux users don't even have your code available from their distro *at
> all* - and that is a direct consequence of this mess we have made
> upstream.
>
> The distros are obviously not acceptably keeping pace with our
> upstream mess. It looks like only Doug and RH are able to keep
> up. IIRC John at SuSE just uses OFED (bleck) rather than sort this all
> out by hand.
>
> Further, we have another pending 2-3 upstream kernel drivers coming
> and I have no idea where to find their userspace components..
And I have no idea, where you can buy these custom based SoCs.
>
> We need to grow up and provide something sensible for our downstreams,
> so our users can get the software easily..
No one is arguing with you about it, the talks are about the process and
responsibilities which need to be cleared BEFORE.
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830060842.GJ594-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-08-30 7:17 ` Christoph Hellwig
[not found] ` <20160830071716.GA3098-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-08-30 16:53 ` Jason Gunthorpe
2016-08-31 17:40 ` Woodruff, Robert J
2 siblings, 1 reply; 174+ messages in thread
From: Christoph Hellwig @ 2016-08-30 7:17 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jason Gunthorpe, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Tue, Aug 30, 2016 at 09:08:42AM +0300, Leon Romanovsky wrote:
> Doug is a busy person and there is a limit on how fast he can handle it.
> He is already buried under his internal and external responsibilities.
>
> Placing him responsible for vendors code will add extra step,
> extra complexity to the chain and will hurt kernel/libibverbs flows.
Leon, calm down. What Jason is proposing is to apply the exact same
flow we have in the kernel to a much smaller project. We prove it
works on a giant project, and it will work on a smaller one.
Maintainer overload always is a problem, and it's helped by adding
more maintainers. And yes, both the kernel RDMA stack and the user
code should have a small maintainer team, but that's a different
discussion.
The current state of RDMA userspace is a complete trainwreck, and
one of the major reasons I can only do testing in very limited
environment - setting all this up on another systems is just too much
work.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830071716.GA3098-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2016-08-30 7:35 ` Leon Romanovsky
[not found] ` <20160830073521.GM594-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-08-30 7:35 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jason Gunthorpe, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On Tue, Aug 30, 2016 at 12:17:16AM -0700, Christoph Hellwig wrote:
> On Tue, Aug 30, 2016 at 09:08:42AM +0300, Leon Romanovsky wrote:
> > Doug is a busy person and there is a limit on how fast he can handle it.
> > He is already buried under his internal and external responsibilities.
> >
> > Placing him responsible for vendors code will add extra step,
> > extra complexity to the chain and will hurt kernel/libibverbs flows.
>
> Leon, calm down. What Jason is proposing is to apply the exact same
> flow we have in the kernel to a much smaller project. We prove it
> works on a giant project, and it will work on a smaller one.
Kernel project has more than "pile of code in one place".
>
> Maintainer overload always is a problem, and it's helped by adding
> more maintainers. And yes, both the kernel RDMA stack and the user
> code should have a small maintainer team, but that's a different
> discussion.
Awesome, let's start from this discussion to clear the ground and move
to technical proposals after it.
>
> The current state of RDMA userspace is a complete trainwreck, and
> one of the major reasons I can only do testing in very limited
> environment - setting all this up on another systems is just too much
> work.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160829203711.GC3201-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-30 8:13 ` Yishai Hadas
[not found] ` <60e502b0-0933-588e-8afe-afead230b2a1-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Yishai Hadas @ 2016-08-30 8:13 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
Majd Dibbiny, liranl-VPRAkNaXOzVWk0Htik3J/w,
talal-VPRAkNaXOzVWk0Htik3J/w, yarong-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
On 8/29/2016 11:37 PM, Jason Gunthorpe wrote:
> On Mon, Aug 29, 2016 at 11:03:45PM +0300, Yishai Hadas wrote:
>
> I'm looking at the git commit activity on mlx4 and mlx5 and I honestly
> don't see your concern, the commit rate is maybe 1 series every 3
> months on mlx5 and even less on mlx4.
Wrong, look at
http://git.openfabrics.org/git/?p=~yishaih/libmlx5.git;a=shortlog, in
the last 7 months there are activities in a monthly basis. When there is
some GAP it was mostly because of waiting to feature acceptances in
libibverbs. (e.g. time stamping).
Also most of the commits in libibverbs are coming from Mellanox in the
last few years. Any new process should consider the ability to move more
faster here, and for sure *not* to come into a case that process is even
slower.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <60e502b0-0933-588e-8afe-afead230b2a1-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2016-08-30 16:10 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-30 16:10 UTC (permalink / raw)
To: Yishai Hadas
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
Majd Dibbiny, liranl-VPRAkNaXOzVWk0Htik3J/w,
talal-VPRAkNaXOzVWk0Htik3J/w, yarong-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w
On Tue, Aug 30, 2016 at 11:13:22AM +0300, Yishai Hadas wrote:
> http://git.openfabrics.org/git/?p=~yishaih/libmlx5.git;a=shortlog, in the
> last 7 months there are activities in a monthly basis. When there is some
> GAP it was mostly because of waiting to feature acceptances in libibverbs.
> (e.g. time stamping).
You are looking at authorship date stamps, I was looking when the
patches were finally commited, that is much more gappy than what the
authorship implies.
There were two series in 2016-06, a big gap and few series in 2016-03,
a few in 2016-02, little around 2015-11, and absolutely nothing till
2015-01.
If you were doing 30 patches/month then I'd worry. But you aren't. At
best one-two series a month, almost all linked with a verbs & kernel
series that have to go through Doug anyhow.
> Also most of the commits in libibverbs are coming from Mellanox in
> the last few years. Any new process should consider the ability to
> move more faster here, and for sure *not* to come into a case that
> process is even slower.
Well, building a better community around verbs and it's standard is an
excellent start.
Having a central rallying point (like Sean has developed with
libfabric) is a positive direction.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830073521.GM594-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-08-30 16:30 ` Jason Gunthorpe
[not found] ` <20160830163033.GC26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-30 16:30 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Tue, Aug 30, 2016 at 10:35:21AM +0300, Leon Romanovsky wrote:
> On Tue, Aug 30, 2016 at 12:17:16AM -0700, Christoph Hellwig wrote:
> > On Tue, Aug 30, 2016 at 09:08:42AM +0300, Leon Romanovsky wrote:
> > > Doug is a busy person and there is a limit on how fast he can handle it.
> > > He is already buried under his internal and external responsibilities.
> > >
> > > Placing him responsible for vendors code will add extra step,
> > > extra complexity to the chain and will hurt kernel/libibverbs flows.
> >
> > Leon, calm down. What Jason is proposing is to apply the exact same
> > flow we have in the kernel to a much smaller project. We prove it
> > works on a giant project, and it will work on a smaller one.
>
> Kernel project has more than "pile of code in one place".
Sigh, that is insulting Leon. I haven't just pulled a bunch of tar
files together. Go look at the commits, and actually try out the
repo. I did a lot of work to harmonize things and there is still more
to do. I just pushed another update for you which includes some of the
cruft removal.
Besides, how do you think the kernel got to where it is today? Do you
think it started out like this? NO. This is a process, starting with a
consolidated repository, getting the distros on board, getting a team
willing to even look at this stuff together, developing a process and
so on.
The first step is the 'make it easy step'. Today everything is just
too hard for developers. When Christoph Hellwig says building our user
space is too hard *you should listen*. He isn't wrong, and he isn't
inexperienced at this.
How many potential community members have been dissuaded by that
simple fact??
> > Maintainer overload always is a problem, and it's helped by adding
> > more maintainers. And yes, both the kernel RDMA stack and the user
> > code should have a small maintainer team, but that's a different
> > discussion.
>
> Awesome, let's start from this discussion to clear the ground and move
> to technical proposals after it.
We've already been over this ground, multiple times over
years. Consolidation is the techincal direction a lot of people want
to move toward.
Whatever maintainership structure is decided on can steward the
consolidated repo.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830054352.GI594-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-08-30 16:47 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-30 16:47 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Jarod Wilson, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Tue, Aug 30, 2016 at 08:43:52AM +0300, Leon Romanovsky wrote:
> Everyone works hard, especially they, and the question is do the distro
> people want to revise their process. The change of upstream process to
> suit their needs is a nice solution, but it needs to be beneficial to
> everyone.
Well, we agree distros get an easier time.
Developers get an easier time because they can test and build our
software without enormous hassle (you do build-test *every* provider
when you change verbs, right?)
They can also submit patches without having to deal with the 15 trees,
MIA maintainers, and unclear process we have today. They get help
following best-practices when working on their providers.
Vendors get more reliable access to *ALL* the distros. It is a
travesty that only Fedora & derived actually have a complete up to date
stack. (kudos to Doug&team for dealing with this mess for so long)
End users could actully build from source, and maybe become
contributors! Wouldn't that be something...
> Current proposal is not good to vendors, who are responsible for
> upstreaming their work.
You are focusing on this really unjustified fear that 'things will
slow down' and missing the bigger picture.
> I disagree that removing old, unsupported libraries from the graves is
> called progress.
Which libraries are these? Granted libibcm is deprecated, but all
other libraries are active or support a still existing kernel driver.
I already ignored all the user space libraries for the kernel drivers
we removed.
If anything what we have here is a substantially *finished* code base
that needs long term maintenance support to keep everything working.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830060842.GJ594-2ukJVAZIZ/Y@public.gmane.org>
2016-08-30 7:17 ` Christoph Hellwig
@ 2016-08-30 16:53 ` Jason Gunthorpe
[not found] ` <20160830165352.GE26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-31 17:40 ` Woodruff, Robert J
2 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-30 16:53 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Steve Wise, 'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Tue, Aug 30, 2016 at 09:08:42AM +0300, Leon Romanovsky wrote:
> > Further, we have another pending 2-3 upstream kernel drivers coming
> > and I have no idea where to find their userspace components..
>
> And I have no idea, where you can buy these custom based SoCs.
Come on Leon. Show some respect to your fellow developers.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830165352.GE26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-30 18:38 ` Leon Romanovsky
0 siblings, 0 replies; 174+ messages in thread
From: Leon Romanovsky @ 2016-08-30 18:38 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, 'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Tue, Aug 30, 2016 at 10:53:52AM -0600, Jason Gunthorpe wrote:
> On Tue, Aug 30, 2016 at 09:08:42AM +0300, Leon Romanovsky wrote:
>
> > > Further, we have another pending 2-3 upstream kernel drivers coming
> > > and I have no idea where to find their userspace components..
> >
> > And I have no idea, where you can buy these custom based SoCs.
>
> Come on Leon. Show some respect to your fellow developers.
What exactly disrespectful did you find in my answer?
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830163033.GC26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-08-30 19:02 ` Leon Romanovsky
2016-09-04 8:18 ` Sagi Grimberg
1 sibling, 0 replies; 174+ messages in thread
From: Leon Romanovsky @ 2016-08-30 19:02 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Christoph Hellwig, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 3322 bytes --]
On Tue, Aug 30, 2016 at 10:30:33AM -0600, Jason Gunthorpe wrote:
> On Tue, Aug 30, 2016 at 10:35:21AM +0300, Leon Romanovsky wrote:
> > On Tue, Aug 30, 2016 at 12:17:16AM -0700, Christoph Hellwig wrote:
> > > On Tue, Aug 30, 2016 at 09:08:42AM +0300, Leon Romanovsky wrote:
> > > > Doug is a busy person and there is a limit on how fast he can handle it.
> > > > He is already buried under his internal and external responsibilities.
> > > >
> > > > Placing him responsible for vendors code will add extra step,
> > > > extra complexity to the chain and will hurt kernel/libibverbs flows.
> > >
> > > Leon, calm down. What Jason is proposing is to apply the exact same
> > > flow we have in the kernel to a much smaller project. We prove it
> > > works on a giant project, and it will work on a smaller one.
> >
> > Kernel project has more than "pile of code in one place".
>
> Sigh, that is insulting Leon. I haven't just pulled a bunch of tar
> files together. Go look at the commits, and actually try out the
> repo. I did a lot of work to harmonize things and there is still more
> to do. I just pushed another update for you which includes some of the
> cruft removal.
"Insulting", you are taking it to far. No one is arguing with you about
the complexity of what you had done. I truly appreciate the effort which
you invested in it, but without the process it is not efficient as it
supposed to be.
>
> Besides, how do you think the kernel got to where it is today? Do you
> think it started out like this? NO. This is a process, starting with a
> consolidated repository, getting the distros on board, getting a team
> willing to even look at this stuff together, developing a process and
> so on.
So let's define a process together.
>
> The first step is the 'make it easy step'. Today everything is just
> too hard for developers. When Christoph Hellwig says building our user
> space is too hard *you should listen*. He isn't wrong, and he isn't
> inexperienced at this.
Sure, I listen, I was in that situation a year ago and still
remember how much time takes to setup the development machine,
but you should read second half of Christoph's answer to me too -
about overwhelmed maintainer in RDMA stack. It is enough to release
that valve "to push the train" and improve the user space domain.
>
> How many potential community members have been dissuaded by that
> simple fact??
>
> > > Maintainer overload always is a problem, and it's helped by adding
> > > more maintainers. And yes, both the kernel RDMA stack and the user
> > > code should have a small maintainer team, but that's a different
> > > discussion.
> >
> > Awesome, let's start from this discussion to clear the ground and move
> > to technical proposals after it.
>
> We've already been over this ground, multiple times over
> years. Consolidation is the techincal direction a lot of people want
> to move toward.
Again, all participants are agree, the disagreement is in
preparation step before such move.
>
> Whatever maintainership structure is decided on can steward the
> consolidated repo.
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830060842.GJ594-2ukJVAZIZ/Y@public.gmane.org>
2016-08-30 7:17 ` Christoph Hellwig
2016-08-30 16:53 ` Jason Gunthorpe
@ 2016-08-31 17:40 ` Woodruff, Robert J
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE04100-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2 siblings, 1 reply; 174+ messages in thread
From: Woodruff, Robert J @ 2016-08-31 17:40 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: Steve Wise, 'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w, Weiny, Ira, Rimmer, Todd
On Tue, Aug 30, 2016 at 09:08:42AM +0300, Leon Romanovsky wrote:
>Doug is a busy person and there is a limit on how fast he can handle it.
>He is already buried under his internal and external responsibilities.
>Placing him responsible for vendors code will add extra step, extra complexity to the chain and will hurt kernel/libibverbs flows.
I agree with Leon on this. Having all of the vendor user libraries bundled in with the core verbs code is just a bad idea.
Most of the H/W vendors I have talked with would prefer that vendor libraries be distributed separately from the core
libibverbs code. The biggest reason for this is to allow vendors to provide incremental updates, bug fixes, etc. to their
customers without having to distribute/update a version of the entire package and/or wait for some third party maintainer
to get around to releasing a new package.
If everything is bundled together, it makes providing incremental updates very problematic.
For example, say vendor A needs to distribute a simple bug fix in their code to a customer so they make a copy of
the bundled package, add their fix and give it to a customer. Seems simple, right ?
But then vendor B has a similar situation and distributes a package with only a fix to their library, but when the customer
Installs it, it overwrites the package provided by vendor A and removes their bug fix.
This kind of thing will end up as a huge disaster for customers and vendors that are trying to support their customers.
So I see some options to avoid this mess.
1.) Keep the vendor user library packages separate from the core libibverbs code, as it is today.
2.) Allow a vendor the ability to distribute their library package separately from the bundled package.
3.) Allow the ability for a vendor to distribute an update package that just contains their library code to replace the
version of that code that is in the bundled package. I think that OFI, for example, has something like this
to avoid this kind of mess.
My 2 cents,
Woody
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE04100-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-08-31 20:03 ` Jason Gunthorpe
[not found] ` <20160831200336.GA4134-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-08-31 20:03 UTC (permalink / raw)
To: Woodruff, Robert J
Cc: Leon Romanovsky, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w, Weiny, Ira
On Wed, Aug 31, 2016 at 05:40:07PM +0000, Woodruff, Robert J wrote:
> If everything is bundled together, it makes providing incremental
> updates very problematic. For example, say vendor A needs to
> distribute a simple bug fix in their code to a customer so they make
> a copy of the bundled package, add their fix and give it to a
> customer. Seems simple, right ? But then vendor B has a similar
> situation and distributes a package with only a fix to their
> library, but when the customer Installs it, it overwrites the
> package provided by vendor A and removes their bug fix. This kind
> of thing will end up as a huge disaster for customers and vendors
> that are trying to support their customers.
Erm, but we already have a mess. AFAIK Mellanox and Intel both use
OFED derivatives as their main means to deliver fixes to customers
that both entirely replace the distro stack and completely conflict
with each other.
So, I'm sorry, I see your scenario as complete fiction today. We are
certainly not making it worse for anyone.
One the contrary, as I pointed out to Mellanox and Chelsio, Intel has
the same problem getting wide distribution of their provider. Is hfi1
even in Fedora yet? Only thing I found was that it was blocked by
review:
https://bugzilla.redhat.com/show_bug.cgi?id=1315870
Let alone Debian..
So, again, your world view of 'rapid updates' seems like a complete
fiction if you have been trying for half a year to enter the
distribution channel. How can you possibly call that a success???
At least ipathverbs seems uniformly distributed in Fedora and Debian,
kudos on that. (though it hasn't changed since 2014, but your release
process is not creating version tags in github, oops)
This would not be such a problem with rdma-plumbing as Fedora would
seemlessly track upstream and all providers from all vendors would
trivially enter the distribution when they regularly pick up the new
upstream. Vendors would no longer have to individually have go to each
distro and lobby for inclusion.
You, again, have missed the major point. Publishing some random code
on a random github is not really distribution. It is not reaching end
users, it is not working effectively. It doesn't matter how quickly
you can update your own vendor private github if the distros simply
ignore it.
IMHO, there is no 'update' until a vendor's provider reach an end user
through their preferred distribution.
> 2.) Allow a vendor the ability to distribute their library package
> separately from the bundled package.
There is nothing stoping this, it is trivial for the vendor to make a
.spec file for rdma-plumbing that just produces a rpm with the single
vendor provider (after doing the full build).
If you really want an example I will show you.
> 3.) Allow the ability for a vendor to distribute an update package
> that just contains their library code to replace the version of that
> code that is in the bundled package. I think that OFI, for example,
> has something like this to avoid this kind of mess.
Certainly, we can make this even easier as well. Mainly what is needed
is some way for the vendor to drop in a override .driver file in
/etc/ibverbs.d/
It would not be hard to make a patch that does that, if that is all it
takes to alleviate your concern I can add it to the todo list.
BTW, it is bit rich to laud Sean for bundling drivers with libfabric
and condem us for doing the same with libibverbs :(
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160831200336.GA4134-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-01 8:26 ` Christoph Hellwig
[not found] ` <20160901082643.GA19799-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-01 14:21 ` Woodruff, Robert J
2016-09-01 15:29 ` ira.weiny
2 siblings, 1 reply; 174+ messages in thread
From: Christoph Hellwig @ 2016-09-01 8:26 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong
This seems to be the entire out of tree driver discussion we
have in the kernel once again. Clueless people at vendors all think
that they are the only ones who matter and let everyone else
suffer.
Jason: how about we start your project and take care of updating the
drivers form the vendor release outselves? I'm pretty sure all
consumers will simply switch to it, eventually forcing the vendors
to work with us.
Arguing with these sorts of bullshit positions from Robert and Leon
just makes me feel tired. I've just seen too many unicorns and special
snowflakes in my life.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901082643.GA19799-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2016-09-01 11:03 ` Leon Romanovsky
[not found] ` <20160901110352.GI3694-2ukJVAZIZ/Y@public.gmane.org>
2016-09-01 17:52 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-01 11:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jason Gunthorpe, Woodruff, Robert J, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
On Thu, Sep 01, 2016 at 01:26:43AM -0700, Christoph Hellwig wrote:
> Arguing with these sorts of bullshit positions from Robert and Leon
> just makes me feel tired.
What are you arguing with us about? These "clueless" people suggested
you the way to move forward and get vendor support to this effort -
convince Doug to add co-maintainer to RDMA stack (kernel and user-space) to
help him to deal with increase in upstream activity.
This co-maintainer won't deal with API's patches (UAPI and libibverbs),
but will help with various internal things (drivers, user-space drivers,
ulps, fixes, e.t.c).
The kernel.org infrastructure allows multiple write access to the same
repository and there are subsystems which are already using it.
If it helps, I can step in and do this job.
Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901110352.GI3694-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-01 12:39 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1609010736370.31007-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2016-09-01 18:14 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Christoph Lameter @ 2016-09-01 12:39 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Jason Gunthorpe, Woodruff, Robert J,
Steve Wise, 'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal
On Thu, 1 Sep 2016, Leon Romanovsky wrote:
> If it helps, I can step in and do this job.
Start by improving on Jason's work? The better Jason's tree becomes the
earlier we will be able to get onto the unified repo. As you contribute
we can work out any issues that may come up in the vendor to upstream
patch flow for these libraries. That may make you more confident in the
speed with which you can get changes in there.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <alpine.DEB.2.20.1609010736370.31007-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
@ 2016-09-01 13:07 ` Leon Romanovsky
[not found] ` <20160901130705.GC21847-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-01 13:07 UTC (permalink / raw)
To: Christoph Lameter
Cc: Christoph Hellwig, Jason Gunthorpe, Woodruff, Robert J,
Steve Wise, 'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
On Thu, Sep 01, 2016 at 07:39:24AM -0500, Christoph Lameter wrote:
> On Thu, 1 Sep 2016, Leon Romanovsky wrote:
>
> > If it helps, I can step in and do this job.
>
> Start by improving on Jason's work? The better Jason's tree becomes the
> earlier we will be able to get onto the unified repo. As you contribute
> we can work out any issues that may come up in the vendor to upstream
> patch flow for these libraries. That may make you more confident in the
> speed with which you can get changes in there.
How nice, I'm pretty sure that Jason will forward code extremely fast.
user space:
Leon -> Jason -> Doug
kernel space (features):
Leon -> Doug
kernel space (fixes):
Leon -> Doug
Do you see bottleneck here?
Maybe it is time to solve root cause and don't hide it?
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901130705.GC21847-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-01 14:11 ` Christoph Lameter
0 siblings, 0 replies; 174+ messages in thread
From: Christoph Lameter @ 2016-09-01 14:11 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Jason Gunthorpe, Woodruff, Robert J,
Steve Wise, 'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal
On Thu, 1 Sep 2016, Leon Romanovsky wrote:
> > Start by improving on Jason's work? The better Jason's tree becomes the
> > earlier we will be able to get onto the unified repo. As you contribute
> > we can work out any issues that may come up in the vendor to upstream
> > patch flow for these libraries. That may make you more confident in the
> > speed with which you can get changes in there.
>
> How nice, I'm pretty sure that Jason will forward code extremely fast.
>
> user space:
> Leon -> Jason -> Doug
> kernel space (features):
> Leon -> Doug
> kernel space (fixes):
> Leon -> Doug
>
> Do you see bottleneck here?
I agree that we need maintainer teams to improve the reaction times to
these issues. How can we form these teams?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160831200336.GA4134-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 8:26 ` Christoph Hellwig
@ 2016-09-01 14:21 ` Woodruff, Robert J
2016-09-01 15:29 ` ira.weiny
2 siblings, 0 replies; 174+ messages in thread
From: Woodruff, Robert J @ 2016-09-01 14:21 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w, Weiny, Ira
On Wed, Aug 31, 2016, Jason Wrote,
>Certainly, we can make this even easier as well. Mainly what is needed is some way for the vendor to drop in a override .driver file >in /etc/ibverbs.d/
>It would not be hard to make a patch that does that, if that is all it takes to alleviate your concern I can add it to the todo list.
I think something like that would work to allow for updates to just a single driver library without having to replace the entire
package, which is what I think people would like to see.
Thanks, that would be great.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (15 preceding siblings ...)
2016-08-22 20:06 ` [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo Steve Wise
@ 2016-09-01 15:24 ` Sagi Grimberg
[not found] ` <4f0876ce-f3c9-83e3-d0ef-0c5656ce9462-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-06 13:59 ` Hal Rosenstock
2016-09-13 16:28 ` Hefty, Sean
18 siblings, 1 reply; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-01 15:24 UTC (permalink / raw)
To: Jason Gunthorpe, Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas, Bart Van Assche
> Hello Everyone,
>
> Here is the patch series for the consolidation. This is based on the special
> merge commit created by the buildlib/make-merge.py script. See my prior
> message (http://www.spinics.net/lists/linux-rdma/msg39026.html) for details.
>
> The first 7 patches change/fix various things in the original packages to
> build consistently, patch 8 has cmake and all the auto* co-exist, and can be
> used to do build compares (see buildlib/compare-build.py)
>
> The next batch of patches removes the old build stuff, packaging, merges
> COPYING files and lightly simplifies the directory structure.
>
> https://github.com/jgunthorpe/rdma-plumbing
>
> This has been rebased since my last posting with feedback from Steve.
>
> The following 15 repositories were pulled together.
>
> libcxgb3 git://git.openfabrics.org/~swise/libcxgb3.git 0de0392268af3a657b329874b63b6ee827109508
> libcxgb4 git://git.openfabrics.org/~swise/libcxgb4.git 15d3253dc814da28e2b93ed02a8e9a96d97f20ae
> libhfi1verbs https://github.com/01org/opa-libhfi1verbs.git 377b68888a0b885fc2a44ddf7a2ec33f2fcf217b
> libi40iw git://git.openfabrics.org/~tnikolova/libi40iw/.git 9d35609f79d6a235e23182e9ceadf3605b2682da
> libibcm git://git.openfabrics.org/~shefty/libibcm.git b04920e8bfe0689a2fe67815321dcf646fd48a7e
> libibumad git://git.openfabrics.org/~halr/libibumad.git ecda3a56b18c6a2845f3d966f8b8061941f5d447
> libibverbs git://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git 0be978ea2bfaf203c35334b090bddb280de62611
> libipathverbs https://github.com/01org/libipathverbs.git 8291d485f3a5544b43974e7be88f3646f35ae07c
> libmlx4 git://git.openfabrics.org/~yishaih/libmlx4.git 162f948c4e04753a15cfb7afcdf6219dbe0bc31e
> libmlx5 git://git.openfabrics.org/~yishaih/libmlx5.git f23f9aa7b9033cd8ebbd58d67d65e9b81d0525fa
> libmthca git://git.kernel.org/pub/scm/libs/infiniband/libmthca.git 6f4dd7451ddef120247e13fa6cb8e1df69c3ddf9
> libnes git://git.openfabrics.org/~tnikolova/libnes/.git 7dc7cf2474612ec909bff251096ca2aefa9cddf1
> libocrdma git://git.openfabrics.org/~emulex/libocrdma.git 41f6bbb3fe8129678c233da439d872b3fe9f75dc
> librdmacm git://git.openfabrics.org/~shefty/librdmacm.git 032bbe60ad32d59004447e03061a9f6d632cc55f
> librxe https://github.com/SoftRoCE/librxe-dev.git 227e3c49b6e423c066e1e1887fe30c8261f63cbd
>
> Steve suggests that iwpm be included as well, which makes sense..
>
> My hope is that Doug will step up as the unified maintainer, with a process
> similar to the kernel. Most of the libraries are unchanging/unmaintained/dead.
Hey Jason,
Sorry for joining the discussion late. This looks *really* nice.
FWIW, I think that it is a good starting point to set a real procedure
to *upstream* user-space development. In the long run I think it's a
win for everyone.
Would it be possible to add srptools in the bundle too?
CC'ing Bart who maintains it.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160831200336.GA4134-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 8:26 ` Christoph Hellwig
2016-09-01 14:21 ` Woodruff, Robert J
@ 2016-09-01 15:29 ` ira.weiny
[not found] ` <20160901152920.GA23742-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
2 siblings, 1 reply; 174+ messages in thread
From: ira.weiny @ 2016-09-01 15:29 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w
On Wed, Aug 31, 2016 at 02:03:36PM -0600, Jason Gunthorpe wrote:
> On Wed, Aug 31, 2016 at 05:40:07PM +0000, Woodruff, Robert J wrote:
>
> > If everything is bundled together, it makes providing incremental
> > updates very problematic. For example, say vendor A needs to
> > distribute a simple bug fix in their code to a customer so they make
> > a copy of the bundled package, add their fix and give it to a
> > customer. Seems simple, right ? But then vendor B has a similar
> > situation and distributes a package with only a fix to their
> > library, but when the customer Installs it, it overwrites the
> > package provided by vendor A and removes their bug fix. This kind
> > of thing will end up as a huge disaster for customers and vendors
> > that are trying to support their customers.
>
> Erm, but we already have a mess. AFAIK Mellanox and Intel both use
> OFED derivatives as their main means to deliver fixes to customers
> that both entirely replace the distro stack and completely conflict
> with each other.
OPA's "delta install" is _not_ based on OFED and installs only the bits which
are needed beyond what is in the distro. Many of those changes already appear
in upstream repos which have not made it into the specific distro version. As
things are accepted we drop those bits from our install. This has been our
policy for some time and if you look at our IFS download you can see that the
packages which get installed for newer distros like 7.2 are smaller than
previous versions.
>
> So, I'm sorry, I see your scenario as complete fiction today. We are
> certainly not making it worse for anyone.
>
> One the contrary, as I pointed out to Mellanox and Chelsio, Intel has
> the same problem getting wide distribution of their provider. Is hfi1
> even in Fedora yet? Only thing I found was that it was blocked by
> review:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1315870
>
> Let alone Debian..
>
> So, again, your world view of 'rapid updates' seems like a complete
> fiction if you have been trying for half a year to enter the
> distribution channel. How can you possibly call that a success???
To some extent this supports Woody's position. libhfi1verbs is being used by
many customers because we can supply it without breaking the standard
libibverbs install. NOTE in Fedora, RHEL, SLES, and others we _do_ _not_
update libibverbs. Thus keeping the standard distro support intact for other
vendors hardware.
>
> At least ipathverbs seems uniformly distributed in Fedora and Debian,
> kudos on that. (though it hasn't changed since 2014, but your release
> process is not creating version tags in github, oops)
>
>
> This would not be such a problem with rdma-plumbing as Fedora would
> seemlessly track upstream and all providers from all vendors would
> trivially enter the distribution when they regularly pick up the new
> upstream. Vendors would no longer have to individually have go to each
> distro and lobby for inclusion.
However, to use the example you have given...
We submitted libhfi1verbs to fedora over 5 months ago 3-8-2016. Due to many
factors it still has not been accepted.
>
> You, again, have missed the major point. Publishing some random code
> on a random github is not really distribution. It is not reaching end
> users, it is not working effectively. It doesn't matter how quickly
> you can update your own vendor private github if the distros simply
> ignore it.
I partly agree with your point. Over all the RDMA vendors have been very
remiss in getting things "really upstream" after they have been accepted
"somewhere". Generally this has been "It's in OFED... done"...
I 100% agree this has to stop. However, offering no "updates" directory for
incoming hardware or critical fixes is too draconian a policy. Reading to the
end of this thread it seems that you and Woody have reached the compromise I
was going to propose. That is...
Similar to the kernel why not have an "updates" directory where new and/or
updated vendor libraries can be installed. While this does provide an out for
vendors to never get their fixes into the common library I for one will push
Intel to not stop there. Intel is committed to fully supporting the community
and distro release mechanisms.
>
> IMHO, there is no 'update' until a vendor's provider reach an end user
> through their preferred distribution.
While I share your sentiment personally the reality is we have many customers
who are actively using OPA hardware with software which is not in any distro
_yet_.
>
> > 2.) Allow a vendor the ability to distribute their library package
> > separately from the bundled package.
>
> There is nothing stoping this, it is trivial for the vendor to make a
> .spec file for rdma-plumbing that just produces a rpm with the single
> vendor provider (after doing the full build).
>
> If you really want an example I will show you.
That could be an alternative.
>
> > 3.) Allow the ability for a vendor to distribute an update package
> > that just contains their library code to replace the version of that
> > code that is in the bundled package. I think that OFI, for example,
> > has something like this to avoid this kind of mess.
>
> Certainly, we can make this even easier as well. Mainly what is needed
> is some way for the vendor to drop in a override .driver file in
> /etc/ibverbs.d/
>
> It would not be hard to make a patch that does that, if that is all it
> takes to alleviate your concern I can add it to the todo list.
Agreed. FWIW I would just add such external updates to an "updates" directory
so that users can easily see that something extra was installed. But this is a
minor point.
>
> BTW, it is bit rich to laud Sean for bundling drivers with libfabric
> and condem us for doing the same with libibverbs :(
FWIW, I believe libfabric offers an external update mechanism. But I have not
had time to verify that in the code.
Ira
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <4f0876ce-f3c9-83e3-d0ef-0c5656ce9462-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
@ 2016-09-01 15:29 ` Steve Wise
2016-09-01 15:56 ` Bart Van Assche
1 sibling, 0 replies; 174+ messages in thread
From: Steve Wise @ 2016-09-01 15:29 UTC (permalink / raw)
To: 'Sagi Grimberg', 'Jason Gunthorpe',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: 'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas',
'Bart Van Assche',
gilr-VPRAkNaXOzVWk0Htik3J/w
> Hey Jason,
>
> Sorry for joining the discussion late. This looks *really* nice.
>
> FWIW, I think that it is a good starting point to set a real procedure
> to *upstream* user-space development. In the long run I think it's a
> win for everyone.
>
> Would it be possible to add srptools in the bundle too?
> CC'ing Bart who maintains it.
I'd also suggest perftest, which provides micro benchmarks:
git://git.openfabrics.org/~grockah/perftest.git master
+Gil Rockah
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <4f0876ce-f3c9-83e3-d0ef-0c5656ce9462-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-01 15:29 ` Steve Wise
@ 2016-09-01 15:56 ` Bart Van Assche
[not found] ` <53eb35b4-0320-acd9-9969-73f5817c8144-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Bart Van Assche @ 2016-09-01 15:56 UTC (permalink / raw)
To: Sagi Grimberg, Jason Gunthorpe, Doug Ledford,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
On 09/01/2016 08:24 AM, Sagi Grimberg wrote:
> Sorry for joining the discussion late. This looks *really* nice.
>
> FWIW, I think that it is a good starting point to set a real procedure
> to *upstream* user-space development. In the long run I think it's a
> win for everyone.
>
> Would it be possible to add srptools in the bundle too?
> CC'ing Bart who maintains it.
Hello Jason and Sagi,
Sorry that I was too busy recently to follow this thread. But I agree
with Sagi - if the purpose is to consolidate all RDMA user space code
then I think the srptools repo should also be included. The official
repo is available at
http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901152920.GA23742-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
@ 2016-09-01 17:09 ` Jason Gunthorpe
[not found] ` <20160901170955.GA19982-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-01 17:09 UTC (permalink / raw)
To: ira.weiny
Cc: Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong
On Thu, Sep 01, 2016 at 11:29:21AM -0400, ira.weiny wrote:
> > Erm, but we already have a mess. AFAIK Mellanox and Intel both use
> > OFED derivatives as their main means to deliver fixes to customers
> > that both entirely replace the distro stack and completely conflict
> > with each other.
>
> OPA's "delta install" is _not_ based on OFED and installs only the bits which
> are needed beyond what is in the distro. Many of those changes already appear
> in upstream repos which have not made it into the specific distro version. As
> things are accepted we drop those bits from our install. This has been our
> policy for some time and if you look at our IFS download you can see that the
> packages which get installed for newer distros like 7.2 are smaller than
> previous versions.
Cool, I am behind the times on that I guess.
However, the my point remains, it still clashes with what MOFED does,
and the idea of two vendors not stomping on each other is still
ficitional.
> To some extent this supports Woody's position. libhfi1verbs is being used by
> many customers because we can supply it without breaking the standard
> libibverbs install. NOTE in Fedora, RHEL, SLES, and others we _do_ _not_
> update libibverbs. Thus keeping the standard distro support intact for other
> vendors hardware.
Well only in the sense that you are on a path that makes it hard to get
into the distros thus requiring you jump through hoops to distribute
your software..
Lets focus on the actual problem :)
> > > 2.) Allow a vendor the ability to distribute their library package
> > > separately from the bundled package.
> >
> > There is nothing stoping this, it is trivial for the vendor to make a
> > .spec file for rdma-plumbing that just produces a rpm with the single
> > vendor provider (after doing the full build).
> >
> > If you really want an example I will show you.
>
> That could be an alternative.
>
> >
> > > 3.) Allow the ability for a vendor to distribute an update package
> > > that just contains their library code to replace the version of that
> > > code that is in the bundled package. I think that OFI, for example,
> > > has something like this to avoid this kind of mess.
> >
> > Certainly, we can make this even easier as well. Mainly what is needed
> > is some way for the vendor to drop in a override .driver file in
> > /etc/ibverbs.d/
> >
> > It would not be hard to make a patch that does that, if that is all it
> > takes to alleviate your concern I can add it to the todo list.
>
> Agreed. FWIW I would just add such external updates to an "updates" directory
> so that users can easily see that something extra was installed. But this is a
> minor point.
I'll write a patch to enable 'run from build' in a way which should
make this even more straight forward.
However, things are already fine today, you just drop your driver in
/opt/intel-opa/lib/libhfi1.so and customize
/etc/libverbs/hfi1verbs.driver with an absolute path to the .so (I
wrote the absolute path patch for this years ago for exactly this
reason)
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <53eb35b4-0320-acd9-9969-73f5817c8144-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
@ 2016-09-01 17:23 ` Jason Gunthorpe
[not found] ` <20160901172355.GA20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-01 17:23 UTC (permalink / raw)
To: Bart Van Assche
Cc: Sagi Grimberg, Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Devesh Sharma, Hal Rosenstock, Mike Marciniszyn, Moni Shoua,
Sean Hefty, Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky,
Yishai Hadas
On Thu, Sep 01, 2016 at 08:56:49AM -0700, Bart Van Assche wrote:
> On 09/01/2016 08:24 AM, Sagi Grimberg wrote:
> >Sorry for joining the discussion late. This looks *really* nice.
> >
> >FWIW, I think that it is a good starting point to set a real procedure
> >to *upstream* user-space development. In the long run I think it's a
> >win for everyone.
> >
> >Would it be possible to add srptools in the bundle too?
> >CC'ing Bart who maintains it.
>
> Hello Jason and Sagi,
>
> Sorry that I was too busy recently to follow this thread. But I agree with
> Sagi - if the purpose is to consolidate all RDMA user space code then I
> think the srptools repo should also be included. The official repo is
> available at http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
Seems reasonable and on theme.
What do you want to do with the emulate_udev directory? It doesn't
even look like it is built..
So we have nominations for
srptools http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
perftest git://git.openfabrics.org/~grockah/perftest.git master
iwpm ?? (Steve Wise: do you have a cannonical link for this, Google isn't
helping me?)
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901082643.GA19799-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-01 11:03 ` Leon Romanovsky
@ 2016-09-01 17:52 ` Jason Gunthorpe
[not found] ` <20160901175230.GD20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-01 17:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong
On Thu, Sep 01, 2016 at 01:26:43AM -0700, Christoph Hellwig wrote:
> This seems to be the entire out of tree driver discussion we
> have in the kernel once again. Clueless people at vendors all think
> that they are the only ones who matter and let everyone else
> suffer.
Yah, exactly, same arguments on both sides, same missed point that the
distros are really driving the show here..
> Jason: how about we start your project and take care of updating the
> drivers form the vendor release outselves? I'm pretty sure all
> consumers will simply switch to it, eventually forcing the vendors
> to work with us.
Yes, that is certainly technically doable.
Though, it kind of makes rdma-plumbing the new OFED so I'd rather like
to see us avoid forking anything.
I think Robert and Leon have come around to the idea anyhow. More
people are on board than not so this is happening on way or another...
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830012738.GH6803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-09-01 18:12 ` Doug Ledford
0 siblings, 0 replies; 174+ messages in thread
From: Doug Ledford @ 2016-09-01 18:12 UTC (permalink / raw)
To: Jarod Wilson
Cc: Jason Gunthorpe, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 1970 bytes --]
On 8/29/2016 9:27 PM, Jarod Wilson wrote:
> On Fri, Aug 26, 2016 at 11:00:22PM -0400, Doug Ledford wrote:
>> On 8/26/2016 6:27 PM, Jason Gunthorpe wrote:
> ...
>>> 3) Version numbers. What version numbers do we give to the sub
>>> packages? I guess this is very distro specific.
>>
>> You can not give different versions to sub-packages. Or, allow me to be
>> more precise: You can't use the Version: tag on sub-packages, it resets
>> the version of the entire package overall when you do. The last
>> Version: tag in the spec file ends up being the version applied to
>> everything. This impacts the %{version} macro usage in the spec file.
>> The only way to put versions on sub-packages is to make it part of the
>> sub-package's name.
>
> I'm not so sure about that. Check out our linux-firmware package and
> sub-packages. There are several firmwares with their own Version: tags in
> their sub-package definitions, and the base linux-firmware package still
> comes out of there with the intended original Version: from the top of the
> spec. I suppose %{version} maybe does get stomped on,
Correct. The %{version} macro gets stomped on, so all of the typical
guidelines about spec files that tell you to use %{version} in various
places have to be ignored.
> but the solution
> I've seen used is to simply set an extra %global and use that where you
> would have used %{version} in the spec.
Yes, that works. But it's an ugly hack and should be taken as a clue
that you are using rpm in a way that it doesn't want to be used ;-)
> That said, I tend to agree with what Doug is saying... If this is all one
> big tree, then it's one big release, and should have one big consistent
> version number, most likely. Otherwise, it's a massive headache and a bit
> of a mess to maintain, package-wise, like he said.
>
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901110352.GI3694-2ukJVAZIZ/Y@public.gmane.org>
2016-09-01 12:39 ` Christoph Lameter
@ 2016-09-01 18:14 ` Jason Gunthorpe
[not found] ` <20160901181421.GE20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-01 18:14 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Woodruff, Robert J, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong
On Thu, Sep 01, 2016 at 02:03:52PM +0300, Leon Romanovsky wrote:
> On Thu, Sep 01, 2016 at 01:26:43AM -0700, Christoph Hellwig wrote:
> > Arguing with these sorts of bullshit positions from Robert and Leon
> > just makes me feel tired.
>
> What are you arguing with us about? These "clueless" people suggested
> you the way to move forward and get vendor support to this effort -
> convince Doug to add co-maintainer to RDMA stack (kernel and user-space) to
> help him to deal with increase in upstream activity.
>
> This co-maintainer won't deal with API's patches (UAPI and libibverbs),
> but will help with various internal things (drivers, user-space drivers,
> ulps, fixes, e.t.c).
>
> The kernel.org infrastructure allows multiple write access to the same
> repository and there are subsystems which are already using it.
>
> If it helps, I can step in and do this job.
I certainly keep hearing a call for a more team oriented approach with
our maintainership, and to me it makes sense that the same basic team
steward the kernel and user plumbing. So I'm supportive of the idea.
I'm less concerned with speed and more with reliablity when Doug is
unavailable and to make sure we are developing community and expertise
in a wider group of people.. The work load only seems to be increasing,
we've hand an unprecedented number of new provider drivers this year.
Doug? This is the sort of discussion I think you need to be leading.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901172355.GA20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-01 18:36 ` Steve Wise
2016-09-02 23:32 ` Jason Gunthorpe
2016-09-01 19:49 ` Doug Ledford
2016-09-04 7:55 ` Sagi Grimberg
2 siblings, 1 reply; 174+ messages in thread
From: Steve Wise @ 2016-09-01 18:36 UTC (permalink / raw)
To: 'Jason Gunthorpe', 'Bart Van Assche'
Cc: 'Sagi Grimberg', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
> On Thu, Sep 01, 2016 at 08:56:49AM -0700, Bart Van Assche wrote:
> > On 09/01/2016 08:24 AM, Sagi Grimberg wrote:
> > >Sorry for joining the discussion late. This looks *really* nice.
> > >
> > >FWIW, I think that it is a good starting point to set a real procedure
> > >to *upstream* user-space development. In the long run I think it's a
> > >win for everyone.
> > >
> > >Would it be possible to add srptools in the bundle too?
> > >CC'ing Bart who maintains it.
> >
> > Hello Jason and Sagi,
> >
> > Sorry that I was too busy recently to follow this thread. But I agree with
> > Sagi - if the purpose is to consolidate all RDMA user space code then I
> > think the srptools repo should also be included. The official repo is
> > available at http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
>
> Seems reasonable and on theme.
>
> What do you want to do with the emulate_udev directory? It doesn't
> even look like it is built..
>
> So we have nominations for
>
> srptools http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
> perftest git://git.openfabrics.org/~grockah/perftest.git master
> iwpm ?? (Steve Wise: do you have a cannonical link for this, Google isn't
> helping me?)
git://git.openfabrics.org/~tnikolova/libiwpm
Tatyana, please correct me if I'm wrong.
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160829062918.GR594-2ukJVAZIZ/Y@public.gmane.org>
2016-08-29 16:00 ` Jason Gunthorpe
@ 2016-09-01 18:51 ` Doug Ledford
[not found] ` <fcfcff11-fe5c-6cf5-3575-52da4b9241ed-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-09-01 18:51 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: Jarod Wilson, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 4816 bytes --]
On 8/29/2016 2:29 AM, Leon Romanovsky wrote:
> On Sun, Aug 28, 2016 at 12:36:27PM -0600, Jason Gunthorpe wrote:
> I'm doing that by running number of one liners [1], it builds me
> development setup in shared folder, so my base image is continuing
> to be clean.
>
> It is not final version, I didn't upload it yet.
>
> Libraries:
> @echo "Build libibverbs"
> @cd $(LIBIBVERBS_SRC)/; ./autogen.sh; ./configure --prefix=$(KVM_SHARED) CFLAGS=-I$(KVM_SHARED)/include LDFLAGS=-L$(KVM_SHARED)/lib CPPFLAGS=-I$(KVM_SHARED)/include; $(MAKE); $(MAKE) install
> @echo "Build libmlx5"
> @cd $(LIBMLX5_SRC)/; ./autogen.sh; ./configure --prefix=$(KVM_SHARED) CFLAGS=-I$(KVM_SHARED)/include LDFLAGS=-L$(KVM_SHARED)/lib CPPFLAGS=-I$(KVM_SHARED)/include; $(MAKE); $(MAKE) install
So, with the changes Jason is proposing, nothing in the above changes
drastically except you can skip all of the "make install" commands
between builds of things like libibverbs and libmlx5 and the libmlx5
build will still be built against the right code, all the time. This is
an improvement in the process from what it is today. Regardless of
distro issues. It's just an improvement period.
>> Doug is also adressing a larger issue with packaging and getting
>> everything to build correctly as the distro - he talked about it here:
>>
>> https://www.spinics.net/lists/linux-rdma/msg37855.html
>
> I read that thread and think that it is related to unoptimized build
> process of one distro who for any reason decided do not use repo tool
> [2]
I'm pretty sure the repo tool didn't exist when Red Hat created their
build process.
> for managing complex build dependencies between different git trees,
We do this on a regular basis. It actually isn't hard for almost
anything besides the RDMA stack.
> but used excel file and manual download of source tarballs.
Just to be clear, *I* used a spreadsheet in tracking my work, that's not
part of the standard workflow inside Red Hat. But when you have a
deadline looming, and 30+ packages to build, and a complex web of
interrelated dependencies, and an overloaded build system because
everyone else is building packages too, it just helps to avoid mistakes
and blown builds if you track your work accurately.
As for source tarballs, this is because when rpm was invented (back in
1994 or so), that's all there was. That was the standard. An argument
could be made that rpm should be updated to work with git repos. I've
made that argument myself, and in some ways it has. But the gold
standard is still source tarballs. Every project has them, they are
easy to verify, and they are constant. According to Fedora's packagedb,
Fedora now has upwards of 20,000 different source packages in total.
Many of these use alternate SCMs, like mercurial, subversion, there
might even be a few still on crusty old CVS. So tarballs are still the
only universal you can get from every project.
> We used such tool for our 100+ git trees project and it worked like a charm.
> There is worth to invest time and revise internal process of releasing
> RDMA stack in that specific distro and no need to invent new beast
> (rdma-plumbers).
Unfortunataely, what you speak of is not really realistic, both for the
reasons I've cited and a whole litany of other reasons I didn't mention.
But I don't think Jason jumped in to work on this because of the goal of
making Red Hat's life easier in packaging up the separate code. He did
it for upstream related reasons:
1) Put all of the providers and libibverbs in one place so that they can
be kept in sync. This allows us to do the exact same thing we do with
the kernel in user space. Namely, if someone makes an incompatible
change in the libibverbs core, we can require that they fix up all
providers in the same patch series. This works rather well for the
kernel, and it would be good to bring that policy to user space too.
2) Put all of the kernel interacting libraries in one place. This makes
it easier to perform the write->ioctl conversion we've been discussing
as there would be only one larger package that needs to be updated for
any given kernel ioctl update.
3) Bring librdmacm and libibverbs together so that the occasional
incompatible update between the two is not an issue any more.
4) Create an easier to build/install package for developers to use.
Those are the issues we should be discussing the relative merits of in
order to determine whether this work should be adopted.
> [1] https://github.com/rleon/dev-scripts/blob/master/Makefile#L89
> [2] https://source.android.com/source/developing.html
>
>>
>> Jason
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901175230.GD20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-01 19:14 ` Woodruff, Robert J
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE04AA2-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Woodruff, Robert J @ 2016-09-01 19:14 UTC (permalink / raw)
To: Jason Gunthorpe, Christoph Hellwig
Cc: Leon Romanovsky, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w, Weiny, Ira
On Thu, Sep 01, 2016 at 10:53 AM, Jason Gunthorpe:
>Though, it kind of makes rdma-plumbing the new OFED so I'd rather like to see us avoid forking anything.
>I think Robert and Leon have come around to the idea anyhow. More people are on board than not so this is happening on way or another...
It certainly has the possibility of making the OFA community OFED packaging and install simpler with less user-space packages to compile/install.
In addition to adding something like .updates to allow incremental updates of individual vendor libraries without having to replace everything,
it would also be desirable to allow someone to selectively build and install a subset of libraries. For example, in the kernel, there is a config file
that allows someone to not build drivers for hardware or kernel features they are not planning on using. People often use that capability so they
can build stripped down versions of the kernel to use in embedded environments where disk and memory space constraints exist.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE04AA2-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-01 19:32 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-01 19:32 UTC (permalink / raw)
To: Woodruff, Robert J
Cc: Christoph Hellwig, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org
On Thu, Sep 01, 2016 at 07:14:38PM +0000, Woodruff, Robert J wrote:
> everything, it would also be desirable to allow someone to
> selectively build and install a subset of libraries. For example,
I don't intend to do this.
The main reason we have it in the kernel is because building every
driver takes hours. rdma-plumbing builds in 3.5 seconds I see no
reason to optimize that further, and I don't forsee us reaching an
onerous build time in the future. Every build builds everything.
Global options like valgrind, libnl, etc are handled at cmake time
just like with configure. These are the only options that might impact
an embedded or otherwise user.
cmake already includes a 'make menuconfig' like tool for these options
(cmake-curses-gui) for those so inclined.
For Intel's case with your delta updates, make a RPM spec file that
does the full build, do the make install and delete everything that
isn't libhfi1 related. Then produce your delta package. You'd build
with options to set the lib install dir to /opt/intel-opa/ (or
whatever) and provide your own .driver file.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901170955.GA19982-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-01 19:38 ` Doug Ledford
[not found] ` <a27267c8-3d5c-cdfe-ed2a-d57cb106a3bf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-02 2:04 ` ira.weiny
1 sibling, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-09-01 19:38 UTC (permalink / raw)
To: Jason Gunthorpe, ira.weiny
Cc: Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1.1: Type: text/plain, Size: 2066 bytes --]
On 9/1/2016 1:09 PM, Jason Gunthorpe wrote:
> I'll write a patch to enable 'run from build' in a way which should
> make this even more straight forward.
>
> However, things are already fine today, you just drop your driver in
> /opt/intel-opa/lib/libhfi1.so and customize
> /etc/libverbs/hfi1verbs.driver with an absolute path to the .so (I
> wrote the absolute path patch for this years ago for exactly this
> reason)
We do have to be a little bit careful here.
1) The override directory needs to be a fixed place.
2) The driver files need to only allow names. The absolute path patch
sounds like an immediate security issue.
3) libibverbs needs to be modified to search the overrides directory
for <name>.so first, then the normal directory. No other searches
should be performed.
4) The overrides directory and the normal directory need to be system
paths so that both file system permissions and SELinux context (if
enabled) prevent random files from being dropped there.
Basically, with the idea you outline above, you would have to change the
file type of the /etc/libibverbs.d/hfi1verbs.driver file (and all the
other driver files) to be a changeable config file, which prevents rpm
(and other) security scanners from being able to detect that it's been
modified (and the modification might be nefarious) and it also means
that on package upgrade, the file is not automatically re-written to the
official form (meaning a nefarious modification would survive a package
update). And with the full path patch, the driver could be pointed to
anywhere. And then you have something like opensm being run as root and
loading up this nefarious driver from wherever. It's a big security issue.
If you instead have just one official override directory, and search it
before the regular directory, then an updated driver can be distributed
as a simple rpm (or deb) that just installs the .so in the right location.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901181421.GE20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-01 19:46 ` Doug Ledford
0 siblings, 0 replies; 174+ messages in thread
From: Doug Ledford @ 2016-09-01 19:46 UTC (permalink / raw)
To: Jason Gunthorpe, Leon Romanovsky
Cc: Christoph Hellwig, Woodruff, Robert J, Steve Wise,
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1.1: Type: text/plain, Size: 2257 bytes --]
On 9/1/2016 2:14 PM, Jason Gunthorpe wrote:
> On Thu, Sep 01, 2016 at 02:03:52PM +0300, Leon Romanovsky wrote:
>> On Thu, Sep 01, 2016 at 01:26:43AM -0700, Christoph Hellwig wrote:
>>> Arguing with these sorts of bullshit positions from Robert and Leon
>>> just makes me feel tired.
>>
>> What are you arguing with us about? These "clueless" people suggested
>> you the way to move forward and get vendor support to this effort -
>> convince Doug to add co-maintainer to RDMA stack (kernel and user-space) to
>> help him to deal with increase in upstream activity.
>>
>> This co-maintainer won't deal with API's patches (UAPI and libibverbs),
>> but will help with various internal things (drivers, user-space drivers,
>> ulps, fixes, e.t.c).
>>
>> The kernel.org infrastructure allows multiple write access to the same
>> repository and there are subsystems which are already using it.
>>
>> If it helps, I can step in and do this job.
>
> I certainly keep hearing a call for a more team oriented approach with
> our maintainership, and to me it makes sense that the same basic team
> steward the kernel and user plumbing. So I'm supportive of the idea.
>
> I'm less concerned with speed and more with reliablity when Doug is
> unavailable and to make sure we are developing community and expertise
> in a wider group of people.. The work load only seems to be increasing,
> we've hand an unprecedented number of new provider drivers this year.
And there are more coming. I had a private discussion with someone just
last night as a matter of fact. It went something like this:
Them: I have a new driver to submit, I think I can have it on list in a
few days, will that be possible to make 4.9?
Me: I doubt it's even possible at this point. Even if you did
everything perfect, there have been so many submissions, and a couple or
three drivers are already on the list waiting inclusion ahead of you,
that I just don't think it's possible to review it in that timeframe.
> Doug? This is the sort of discussion I think you need to be leading.
I'm going to think about this for a bit...more later today...
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901172355.GA20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 18:36 ` Steve Wise
@ 2016-09-01 19:49 ` Doug Ledford
[not found] ` <3a266ff7-006f-3d27-9e07-9e2e3ba2d1f9-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-04 7:55 ` Sagi Grimberg
2 siblings, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-09-01 19:49 UTC (permalink / raw)
To: Jason Gunthorpe, Bart Van Assche
Cc: Sagi Grimberg, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Mike Marciniszyn, Moni Shoua, Sean Hefty,
Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky, Yishai Hadas
[-- Attachment #1.1: Type: text/plain, Size: 1905 bytes --]
On 9/1/2016 1:23 PM, Jason Gunthorpe wrote:
> On Thu, Sep 01, 2016 at 08:56:49AM -0700, Bart Van Assche wrote:
>> On 09/01/2016 08:24 AM, Sagi Grimberg wrote:
>>> Sorry for joining the discussion late. This looks *really* nice.
>>>
>>> FWIW, I think that it is a good starting point to set a real procedure
>>> to *upstream* user-space development. In the long run I think it's a
>>> win for everyone.
>>>
>>> Would it be possible to add srptools in the bundle too?
>>> CC'ing Bart who maintains it.
>>
>> Hello Jason and Sagi,
>>
>> Sorry that I was too busy recently to follow this thread. But I agree with
>> Sagi - if the purpose is to consolidate all RDMA user space code then I
>> think the srptools repo should also be included. The official repo is
>> available at http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
>
> Seems reasonable and on theme.
>
> What do you want to do with the emulate_udev directory? It doesn't
> even look like it is built..
>
> So we have nominations for
>
> srptools http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
> perftest git://git.openfabrics.org/~grockah/perftest.git master
I would drop perftest out. Here's why. I like the idea that this
package is for software that interacts with the kernel directly. It
needs to, in some way, involve itself with the kernel char interface or
with the kernel netlink interface. So far, everything meets that
critera. Perftest does not. So, in the same fashion as libfabrics and
fabtests, I would leave perftest out, but that isn't to say a separate
package that pulled together various testing apps for RDMA could be
created too.
> iwpm ?? (Steve Wise: do you have a cannonical link for this, Google isn't
> helping me?)
>
> Jason
>
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <3a266ff7-006f-3d27-9e07-9e2e3ba2d1f9-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-09-01 19:52 ` Steve Wise
2016-09-01 20:21 ` Jason Gunthorpe
0 siblings, 1 reply; 174+ messages in thread
From: Steve Wise @ 2016-09-01 19:52 UTC (permalink / raw)
To: 'Doug Ledford', 'Jason Gunthorpe',
'Bart Van Assche'
Cc: 'Sagi Grimberg',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
> >
> > So we have nominations for
> >
> > srptools http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
> > perftest git://git.openfabrics.org/~grockah/perftest.git master
>
> I would drop perftest out. Here's why. I like the idea that this
> package is for software that interacts with the kernel directly. It
> needs to, in some way, involve itself with the kernel char interface or
> with the kernel netlink interface. So far, everything meets that
> critera. Perftest does not. So, in the same fashion as libfabrics and
> fabtests, I would leave perftest out, but that isn't to say a separate
> package that pulled together various testing apps for RDMA could be
> created too.
>
I see your point. That is fine with me.
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <a27267c8-3d5c-cdfe-ed2a-d57cb106a3bf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-09-01 20:17 ` Jason Gunthorpe
[not found] ` <20160901201727.GG20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-01 20:17 UTC (permalink / raw)
To: Doug Ledford
Cc: ira.weiny, Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong
On Thu, Sep 01, 2016 at 03:38:13PM -0400, Doug Ledford wrote:
> On 9/1/2016 1:09 PM, Jason Gunthorpe wrote:
>
> > I'll write a patch to enable 'run from build' in a way which should
> > make this even more straight forward.
> >
> > However, things are already fine today, you just drop your driver in
> > /opt/intel-opa/lib/libhfi1.so and customize
> > /etc/libverbs/hfi1verbs.driver with an absolute path to the .so (I
> > wrote the absolute path patch for this years ago for exactly this
> > reason)
>
> We do have to be a little bit careful here.
Nothing I describe requires any support beyond what we have today..
So if there is an actual security issue you need to make it clear and
we need to deal with it right away.
However, I don't see your logic.
> 1) The override directory needs to be a fixed place.
/etc/libibverbs.d/*.driver is the standard drop in place we used, and is
already used by every provider driver.
> 2) The driver files need to only allow names. The absolute path patch
> sounds like an immediate security issue.
The patch for this has been in for years now.
> 3) libibverbs needs to be modified to search the overrides directory
> for <name>.so first, then the normal directory. No other searches
> should be performed.
libibverbs does not search paths. It dlopens "libfoo-rdmav2.so" and
libdl searches the system search path for that name. AFAIK the user
can override this search with LD_LIBRARY_PATH like any other dynamic
link. (of course automatically prevented by libdl for setuid)
If *.driver specifies an absolute filename then libdl opens only that
file.
We do not want libibverbs to search paths directly because that breaks
biarch and other configurations. It is best to let libdl handle this.
> 4) The overrides directory and the normal directory need to be system
> paths so that both file system permissions and SELinux context (if
> enabled) prevent random files from being dropped there.
Of course. selinux/etc should apply the same protections to modifying
the .driver files and the containing directory as it applies to
modifying the system .so's. (ie only root can do it)
This is super critical.
> Basically, with the idea you outline above, you would have to change the
> file type of the /etc/libibverbs.d/hfi1verbs.driver file (and all the
> other driver files) to be a changeable config file, which prevents rpm
> (and other) security scanners from being able to detect that it's
> been
Really? You are shipping things in /etc/ and they are not marked config
files? That doesn't violate your distro policies?
The entire point of these files, the only reason we have them at all,
and the reason they are in /etc/, is *specifically* so users can
configure the search path and customize the driver choice.
Otherwise we'd just dlopen("<kern-name>-rdmav2.so") and eliminate this
configurability entirely. We certainly do not need the data stored in
the .driver files to operate libibverbs. And indeed that
auto-configurability is the basic approach I am thinking of to enable
run-from-build.
So I view the lack of config marking as a packaging bug, sorry.
> anywhere. And then you have something like opensm being run as root and
> loading up this nefarious driver from wherever. It's a big security issue.
This makes no sense. As above, access to the .driver files must
require the same privledge to write as write to the .so libraries.
If an attacker can access the .driver files then they can access the
.so, then the attacker can just replace libc.so, and game over.
I think any possible attack avenue would have to involve setuid. Eg
trick a setuid program using libibverbs to dlopen a user controlled .so.
I don't have an avenue in mind though, that would require replacing
/etc/ with something else, and AFAIK, the ability to do that would
make other setuid programs like su and sudo insecure??
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-01 19:52 ` Steve Wise
@ 2016-09-01 20:21 ` Jason Gunthorpe
[not found] ` <20160901202110.GH20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-01 20:21 UTC (permalink / raw)
To: Steve Wise
Cc: 'Doug Ledford', 'Bart Van Assche',
'Sagi Grimberg',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Thu, Sep 01, 2016 at 02:52:55PM -0500, Steve Wise wrote:
> > >
> > > So we have nominations for
> > >
> > > srptools http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
> > > perftest git://git.openfabrics.org/~grockah/perftest.git master
> >
> > I would drop perftest out. Here's why. I like the idea that this
> > package is for software that interacts with the kernel directly. It
> > needs to, in some way, involve itself with the kernel char interface or
> > with the kernel netlink interface. So far, everything meets that
> > critera. Perftest does not. So, in the same fashion as libfabrics and
> > fabtests, I would leave perftest out, but that isn't to say a separate
> > package that pulled together various testing apps for RDMA could be
> > created too.
> >
>
> I see your point. That is fine with me.
I'm happy either way, but I will point out that libibverbs and
librdmacm sources contains various things similar to perftest (eg the
pingpong stuff, _bw, etc).
If we were to merge perftest I'd probably aim to consolidate all of
those similar examples/tests/etc under one directory in the source
tree.
I'd cast perftest and related as diagnostic tools to help users
validate verbs hardware is working as expected, so still under the
plumbing umbrella.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901170955.GA19982-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 19:38 ` Doug Ledford
@ 2016-09-02 2:04 ` ira.weiny
[not found] ` <20160902020411.GD23742-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: ira.weiny @ 2016-09-02 2:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w
On Thu, Sep 01, 2016 at 11:09:55AM -0600, Jason Gunthorpe wrote:
> On Thu, Sep 01, 2016 at 11:29:21AM -0400, ira.weiny wrote:
>
> > > Erm, but we already have a mess. AFAIK Mellanox and Intel both use
> > > OFED derivatives as their main means to deliver fixes to customers
> > > that both entirely replace the distro stack and completely conflict
> > > with each other.
> >
> > OPA's "delta install" is _not_ based on OFED and installs only the bits which
> > are needed beyond what is in the distro. Many of those changes already appear
> > in upstream repos which have not made it into the specific distro version. As
> > things are accepted we drop those bits from our install. This has been our
> > policy for some time and if you look at our IFS download you can see that the
> > packages which get installed for newer distros like 7.2 are smaller than
> > previous versions.
>
> Cool, I am behind the times on that I guess.
>
> However, the my point remains, it still clashes with what MOFED does,
> and the idea of two vendors not stomping on each other is still
> ficitional.
How does it conflict with MOFED if we do _not_ change libmlx*, libibumad,
librdmacm, libibverbs, and only add an updated hfi1.ko?
>
> > To some extent this supports Woody's position. libhfi1verbs is being used by
> > many customers because we can supply it without breaking the standard
> > libibverbs install. NOTE in Fedora, RHEL, SLES, and others we _do_ _not_
> > update libibverbs. Thus keeping the standard distro support intact for other
> > vendors hardware.
>
> Well only in the sense that you are on a path that makes it hard to get
> into the distros thus requiring you jump through hoops to distribute
> your software..
I'm not sure I understand how we are on a path which makes it hard to get into
the distros?
>
> Lets focus on the actual problem :)
>
> > > > 2.) Allow a vendor the ability to distribute their library package
> > > > separately from the bundled package.
> > >
> > > There is nothing stoping this, it is trivial for the vendor to make a
> > > .spec file for rdma-plumbing that just produces a rpm with the single
> > > vendor provider (after doing the full build).
> > >
> > > If you really want an example I will show you.
> >
> > That could be an alternative.
> >
> > >
> > > > 3.) Allow the ability for a vendor to distribute an update package
> > > > that just contains their library code to replace the version of that
> > > > code that is in the bundled package. I think that OFI, for example,
> > > > has something like this to avoid this kind of mess.
> > >
> > > Certainly, we can make this even easier as well. Mainly what is needed
> > > is some way for the vendor to drop in a override .driver file in
> > > /etc/ibverbs.d/
> > >
> > > It would not be hard to make a patch that does that, if that is all it
> > > takes to alleviate your concern I can add it to the todo list.
> >
> > Agreed. FWIW I would just add such external updates to an "updates" directory
> > so that users can easily see that something extra was installed. But this is a
> > minor point.
>
> I'll write a patch to enable 'run from build' in a way which should
> make this even more straight forward.
Sounds good...
Ira
>
> However, things are already fine today, you just drop your driver in
> /opt/intel-opa/lib/libhfi1.so and customize
> /etc/libverbs/hfi1verbs.driver with an absolute path to the .so (I
> wrote the absolute path patch for this years ago for exactly this
> reason)
>
> Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160902020411.GD23742-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
@ 2016-09-02 17:18 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-02 17:18 UTC (permalink / raw)
To: ira.weiny
Cc: Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong
On Thu, Sep 01, 2016 at 10:04:12PM -0400, ira.weiny wrote:
> > However, the my point remains, it still clashes with what MOFED does,
> > and the idea of two vendors not stomping on each other is still
> > ficitional.
>
> How does it conflict with MOFED if we do _not_ change libmlx*, libibumad,
> librdmacm, libibverbs, and only add an updated hfi1.ko?
MOFED ships new core kernel modules, so I doubt hfi1.ko will load
after MOFED is installed.
MOFED has historically shipped a libibverbs that does not follow
upstream's ABI in subtle ways. I would not anticipate that your
libhfi1-rdmav2 would work fully correctly either.
They may even ship libhfi1 since it is in OFED and they are deriving
from OFED. I haven't checked.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-01 18:36 ` Steve Wise
@ 2016-09-02 23:32 ` Jason Gunthorpe
[not found] ` <20160902233231.GA26309-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-02 23:32 UTC (permalink / raw)
To: Steve Wise
Cc: 'Bart Van Assche', 'Sagi Grimberg',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Thu, Sep 01, 2016 at 01:36:16PM -0500, Steve Wise wrote:
> > Seems reasonable and on theme.
> >
> > What do you want to do with the emulate_udev directory? It doesn't
> > even look like it is built..
> >
> > So we have nominations for
> >
> > srptools http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
> > perftest git://git.openfabrics.org/~grockah/perftest.git master
> > iwpm ?? (Steve Wise: do you have a cannonical link for this, Google isn't
> > helping me?)
>
> git://git.openfabrics.org/~tnikolova/libiwpm
>
> Tatyana, please correct me if I'm wrong.
Bart, Steve, Sagi:
Done. I left out perftest as Doug requested.
https://github.com/jgunthorpe/rdma-plumbing
We will need to get a systemd service file for srp_daemon, and iwpm
is missing man pages, but those are pre-existing problems.
Can you please let me know if this works for you?
iwpm in particular didn't even build (auto* drift) on a modern distro
so I'm a bit skeptical...
Be aware, by default 'make install' will not install the boot files
for iwpm or srp_daemon in any useful place (as per GNU
convention).
I recommend trying the sample rpm spec file, which does the right
thing.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160902233231.GA26309-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-03 0:10 ` Bart Van Assche
[not found] ` <ef8214f8-d44d-2289-d1ed-a0998e9e05c0-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-09-04 21:47 ` Doug Ledford
1 sibling, 1 reply; 174+ messages in thread
From: Bart Van Assche @ 2016-09-03 0:10 UTC (permalink / raw)
To: Jason Gunthorpe, Steve Wise
Cc: 'Sagi Grimberg', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On 09/02/2016 04:32 PM, Jason Gunthorpe wrote:
> On Thu, Sep 01, 2016 at 01:36:16PM -0500, Steve Wise wrote:
>>> Seems reasonable and on theme.
>>>
>>> What do you want to do with the emulate_udev directory? It doesn't
>>> even look like it is built..
>>>
>>> So we have nominations for
>>>
>>> srptools http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
>>> perftest git://git.openfabrics.org/~grockah/perftest.git master
>>> iwpm ?? (Steve Wise: do you have a cannonical link for this, Google isn't
>>> helping me?)
>>
>> git://git.openfabrics.org/~tnikolova/libiwpm
>>
>> Tatyana, please correct me if I'm wrong.
>
> Bart, Steve, Sagi:
>
> Done. I left out perftest as Doug requested.
>
> https://github.com/jgunthorpe/rdma-plumbing
>
> We will need to get a systemd service file for srp_daemon, and iwpm
> is missing man pages, but those are pre-existing problems.
>
> Can you please let me know if this works for you?
>
> iwpm in particular didn't even build (auto* drift) on a modern distro
> so I'm a bit skeptical...
>
> Be aware, by default 'make install' will not install the boot files
> for iwpm or srp_daemon in any useful place (as per GNU
> convention).
>
> I recommend trying the sample rpm spec file, which does the right
> thing.
Hello Jason,
Can you have a look at the patch below? I needed it to make the spec
file usable on my development system.
Thanks,
Bart.
[PATCH] rdma-plumbing.spec: Port to SuSE platforms
Additionally, fix a syntax error in the non-ninja section.
Signed-off-by: Bart Van Assche <bart.vanassche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
---
rdma-plumbing.spec | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/rdma-plumbing.spec b/rdma-plumbing.spec
index 050df0c..acb24bc 100644
--- a/rdma-plumbing.spec
+++ b/rdma-plumbing.spec
@@ -16,17 +16,24 @@ BuildRequires: pkgconfig(libnl-3.0)
BuildRequires: pkgconfig(libnl-route-3.0)
BuildRequires: valgrind-devel
-%if 0%{?fedora} >= 23
# Since we recommend developers use Ninja, so should packagers, for consistency.
+%if %{expand:%%(rpm -q kernel-default >/dev/null 2>&1; echo $((1-$?)))}
+# openSuSE or SLES
+BuildRequires: ninja
+%define CMAKE_FLAG -GNinja
+%define MAKE_CMD ninja -v
+%else
+%if 0%{?fedora} >= 23
# Ninja was introduced in FC23 and has not yet made it to an EL.
BuildRequires: ninja-build
%define CMAKE_FLAG -GNinja
%define MAKE_CMD ninja-build -v
%else
BuildRequires: make
-%define CMAKE_FLAG
+%define CMAKE_FLAG %{nil}
%define MAKE_CMD make
%endif
+%endif
%description
Temporary packaging
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <ef8214f8-d44d-2289-d1ed-a0998e9e05c0-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
@ 2016-09-03 5:12 ` Jason Gunthorpe
2016-09-03 14:08 ` Bart Van Assche
[not found] ` <20160903051222.GA2098-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 2 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-03 5:12 UTC (permalink / raw)
To: Bart Van Assche
Cc: Steve Wise, 'Sagi Grimberg', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Fri, Sep 02, 2016 at 05:10:45PM -0700, Bart Van Assche wrote:
> Can you have a look at the patch below? I needed it to make the spec
> file usable on my development system.
Interesting. Thanks Bart
> -%define CMAKE_FLAG
> +%define CMAKE_FLAG %{nil}
Weird, I didn't know opensuse rpmbuild was different.. But that hunk is
fine, c6 and c7 accept it as well, but don't need it..
So I added opensuse 13.2 and 42.1 to the list of docker container
builders and the simple build looks like it runs OK.
But rpmbuild chokes even after the above fix.
What suse version are you using to have any success at all? I suppose
it isn't available in docker?
Looks like opensuse uses a different %cmake macro. Totally different
in fact.
Scary macros.
I will need to look at it alot more to get 13.2 and 42.1 to rpmbuild, is
that of value to you or anyone else?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-03 5:12 ` Jason Gunthorpe
@ 2016-09-03 14:08 ` Bart Van Assche
[not found] ` <BLUPR02MB16836859F638150FF6330A0A81E40-Y8PPn9RqzNfZ9ihocuPUdanrV9Ap65cLvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
[not found] ` <20160903051222.GA2098-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Bart Van Assche @ 2016-09-03 14:08 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, 'Sagi Grimberg', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On 09/02/16 22:12, Jason Gunthorpe wrote:
> On Fri, Sep 02, 2016 at 05:10:45PM -0700, Bart Van Assche wrote:
>> -%define CMAKE_FLAG
>> +%define CMAKE_FLAG %{nil}
>
> Weird, I didn't know opensuse rpmbuild was different.. But that hunk is
> fine, c6 and c7 accept it as well, but don't need it..
Hello Jason,
I don't think that "%define CMAKE_FLAG" is syntactically valid. See e.g.
http://stackoverflow.com/questions/3474674/how-to-define-a-rpm-spec-macro-with-empty-body.
> So I added opensuse 13.2 and 42.1 to the list of docker container
> builders and the simple build looks like it runs OK.
>
> But rpmbuild chokes even after the above fix.
>
> What suse version are you using to have any success at all? I suppose
> it isn't available in docker?
On my development system I run openSuSE Tumbleweed, a rolling release. I
update it every now and then by running "zypper dist-upgrade". Some of
our production systems run SLES 12 SP2; others run RHEL 6 or RHEL 7.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160903051222.GA2098-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-04 5:54 ` Leon Romanovsky
[not found] ` <20160904055441.GI21847-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-04 5:54 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Bart Van Assche, Steve Wise, 'Sagi Grimberg',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
On Fri, Sep 02, 2016 at 11:12:22PM -0600, Jason Gunthorpe wrote:
> On Fri, Sep 02, 2016 at 05:10:45PM -0700, Bart Van Assche wrote:
>
> So I added opensuse 13.2 and 42.1 to the list of docker container
> builders and the simple build looks like it runs OK.
Are you running standard docker containers or build them by yourself?
Can you add scripts to run containers to your rdma-plumbers repo? So it
will be much easier to see/debug build issues on different platforms.
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901172355.GA20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 18:36 ` Steve Wise
2016-09-01 19:49 ` Doug Ledford
@ 2016-09-04 7:55 ` Sagi Grimberg
2016-09-04 15:07 ` Bart Van Assche
2 siblings, 1 reply; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-04 7:55 UTC (permalink / raw)
To: Jason Gunthorpe, Bart Van Assche
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Mike Marciniszyn, Moni Shoua, Sean Hefty,
Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky, Yishai Hadas
> Seems reasonable and on theme.
>
> What do you want to do with the emulate_udev directory? It doesn't
> even look like it is built..
I think we can safely drop it. It's been there forever and never been
used AFAIK. Bart?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160830163033.GC26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-30 19:02 ` Leon Romanovsky
@ 2016-09-04 8:18 ` Sagi Grimberg
[not found] ` <4b791de5-0d6e-fd94-8a31-2fe833ca72db-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-04 8:18 UTC (permalink / raw)
To: Jason Gunthorpe, Leon Romanovsky
Cc: Christoph Hellwig, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
> The first step is the 'make it easy step'. Today everything is just
> too hard for developers. When Christoph Hellwig says building our user
> space is too hard *you should listen*. He isn't wrong, and he isn't
> inexperienced at this.
>
> How many potential community members have been dissuaded by that
> simple fact??
I like where this is going. It would also resolve the question
"who is upstream?" that I had a few times in the past with all
the scattered repos online (ofa, github...)
>>> Maintainer overload always is a problem, and it's helped by adding
>>> more maintainers. And yes, both the kernel RDMA stack and the user
>>> code should have a small maintainer team, but that's a different
>>> discussion.
>>
>> Awesome, let's start from this discussion to clear the ground and move
>> to technical proposals after it.
>
> We've already been over this ground, multiple times over
> years. Consolidation is the techincal direction a lot of people want
> to move toward.
Leon's concerns are justified I think. Mellanox as the most significant
contributor here should not suffer delays from this. But generally if
we build a healthy community, with active maintainers (which share the
load) and clear release cycles, I think we can actually accelerate the
process.
> Whatever maintainership structure is decided on can steward the
> consolidated repo.
I think that having a maintainer per provider makes perfect sense
and as long as you Jason (or anyone else) are committed to merging it
all together and produce standard releases we are pretty much set.
What I think it missing is a release schedule, stable fixes
methodology and merge cycles. I think once we can agree on that
a lot of the concerns will be addressed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <4b791de5-0d6e-fd94-8a31-2fe833ca72db-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
@ 2016-09-04 8:35 ` Leon Romanovsky
[not found] ` <20160904083517.GN21847-2ukJVAZIZ/Y@public.gmane.org>
2016-09-06 7:01 ` Christoph Hellwig
2016-09-06 19:38 ` Jason Gunthorpe
2 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-04 8:35 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Jason Gunthorpe, Christoph Hellwig, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
On Sun, Sep 04, 2016 at 11:18:02AM +0300, Sagi Grimberg wrote:
> What I think it missing is a release schedule, stable fixes
> methodology and merge cycles. I think once we can agree on that
> a lot of the concerns will be addressed.
This is exactly my point.
What do you think if we follow kernel release cycles and schedules? It
will give to everyone in RDMA world clear answer on WHEN question.
Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160904083517.GN21847-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-04 10:36 ` Sagi Grimberg
[not found] ` <a220db98-ebbf-5df4-e011-8804442796b8-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-04 10:36 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Jason Gunthorpe, Christoph Hellwig, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
>> What I think it missing is a release schedule, stable fixes
>> methodology and merge cycles. I think once we can agree on that
>> a lot of the concerns will be addressed.
>
> This is exactly my point.
> What do you think if we follow kernel release cycles and schedules? It
> will give to everyone in RDMA world clear answer on WHEN question.
That can work. But, I think that we need the stable fixes to be released
more frequently (Ideally on-demand, but it might be too much of an
overhead both to maintainers and users).
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-04 7:55 ` Sagi Grimberg
@ 2016-09-04 15:07 ` Bart Van Assche
0 siblings, 0 replies; 174+ messages in thread
From: Bart Van Assche @ 2016-09-04 15:07 UTC (permalink / raw)
To: Sagi Grimberg, Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Mike Marciniszyn, Moni Shoua, Sean Hefty,
Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky, Yishai Hadas
On 09/04/16 00:55, Sagi Grimberg wrote:
>> Seems reasonable and on theme.
>>
>> What do you want to do with the emulate_udev directory? It doesn't
>> even look like it is built..
>
> I think we can safely drop it. It's been there forever and never been
> used AFAIK. Bart?
It is safe to remove that code. I have dropped it from the official
srptools repository.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901201727.GG20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-04 21:38 ` Doug Ledford
[not found] ` <9efe8c8f-40e2-b016-9a1e-4770298b9068-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-09-04 21:38 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: ira.weiny, Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w, yar
[-- Attachment #1.1: Type: text/plain, Size: 8378 bytes --]
On 9/1/2016 4:17 PM, Jason Gunthorpe wrote:
> On Thu, Sep 01, 2016 at 03:38:13PM -0400, Doug Ledford wrote:
>> On 9/1/2016 1:09 PM, Jason Gunthorpe wrote:
>>
>>> I'll write a patch to enable 'run from build' in a way which should
>>> make this even more straight forward.
>>>
>>> However, things are already fine today, you just drop your driver in
>>> /opt/intel-opa/lib/libhfi1.so and customize
>>> /etc/libverbs/hfi1verbs.driver with an absolute path to the .so (I
>>> wrote the absolute path patch for this years ago for exactly this
>>> reason)
>>
>> We do have to be a little bit careful here.
>
> Nothing I describe requires any support beyond what we have today..
>
> So if there is an actual security issue you need to make it clear and
> we need to deal with it right away.
>
> However, I don't see your logic.
>
>> 1) The override directory needs to be a fixed place.
>
> /etc/libibverbs.d/*.driver is the standard drop in place we used, and is
> already used by every provider driver.
I meant the .so's override directory. I'm assuming the actual .so name
for an override driver will have the same name as the default .so, so
you need a second directory. I would make that directory a fixed,
standard location.
>> 2) The driver files need to only allow names. The absolute path patch
>> sounds like an immediate security issue.
>
> The patch for this has been in for years now.
It might be worth removing it, or at least analyzing it in more detail...
>> 3) libibverbs needs to be modified to search the overrides directory
>> for <name>.so first, then the normal directory. No other searches
>> should be performed.
>
> libibverbs does not search paths. It dlopens "libfoo-rdmav2.so" and
> libdl searches the system search path for that name. AFAIK the user
> can override this search with LD_LIBRARY_PATH like any other dynamic
> link. (of course automatically prevented by libdl for setuid)
>
> If *.driver specifies an absolute filename then libdl opens only that
> file.
>
> We do not want libibverbs to search paths directly because that breaks
> biarch and other configurations. It is best to let libdl handle this.
It won't break biarch. You can't load a 32bit .so with a 64bit
libibverbs and vice versa, so you can put the .so library path into your
binary based upon arch. I would do this in preference to libdl searches.
>> 4) The overrides directory and the normal directory need to be system
>> paths so that both file system permissions and SELinux context (if
>> enabled) prevent random files from being dropped there.
>
> Of course. selinux/etc should apply the same protections to modifying
> the .driver files and the containing directory as it applies to
> modifying the system .so's. (ie only root can do it)
>
> This is super critical.
It's not just the permissions to modify, it's the file's default
context. Many files in SELinux parlance inherit their default context
based upon their location. If you want to have a specific rdma_driver_t
context, you would need a directory specifically for them so you can
have an SELinux inheritance rule that sets the driver's context.
Historically, there hasn't been much in the way of SELinux rules related
to RDMA stuff, but I know that's actively changing as I've been involved
inside Red Hat with some of the very beginning stages of new rules and
contexts.
>> Basically, with the idea you outline above, you would have to change the
>> file type of the /etc/libibverbs.d/hfi1verbs.driver file (and all the
>> other driver files) to be a changeable config file, which prevents rpm
>> (and other) security scanners from being able to detect that it's
>> been
>
> Really? You are shipping things in /etc/ and they are not marked config
> files? That doesn't violate your distro policies?
Generally all files in /etc are %config in their RPM tags. But there
are two different %config markings in RPM, there is %config and
%config(noreplace). On rpm upgrade of a package, any file marked
%config is overwritten with the new file. If the old file had been
modified, it is saved as <filename>.rpmold. If the file is
%config(noreplace), then on upgrade the new file will not overwrite the
old file, and if the new file varies from the old file in the previous
rpm, then the new file is saved as <filename>.rpmnew. My comment above
is that in order to support modifying those driver files and not having
those modifications get wiped out on upgrade, the config files must be
marked as %config(noreplace) and that means we will preserve changes.
That's both good and bad in that the changes can be a user's desired
intent, or a nefarious user's subterfuge. Now, if it nefarious, then
the admin could check for the presence of an .rpmnew file after each
upgrade, but as admin's are sometimes slack on that, it could slip under
the radar.
But really, with what I talked about above, with us creating two
directories, a standard and an override directory, and using that to
have SELinux file context inheritance, we can actually do away with all
of the /etc/libibverbs.d/* files entirely because we wouldn't need them
any more. For proper SELinux support of a targeted subsystem, and the
RDMA stack really kinda deserves that because of the damage RDMA can do
in the wrong hands, this is almost mandatory.
> The entire point of these files, the only reason we have them at all,
> and the reason they are in /etc/, is *specifically* so users can
> configure the search path and customize the driver choice.
>
> Otherwise we'd just dlopen("<kern-name>-rdmav2.so") and eliminate this
> configurability entirely. We certainly do not need the data stored in
> the .driver files to operate libibverbs. And indeed that
> auto-configurability is the basic approach I am thinking of to enable
> run-from-build.
>
> So I view the lack of config marking as a packaging bug, sorry.
>
>> anywhere. And then you have something like opensm being run as root and
>> loading up this nefarious driver from wherever. It's a big security issue.
>
> This makes no sense. As above, access to the .driver files must
> require the same privledge to write as write to the .so libraries.
A text config file is easier to manage a hack on that a .so. If your
library simply doesn't read any text config files and instead has
SELinux secured .so's in a well protected place, that is more secure.
Yes, you would need root in order to modify the driver config text files
if you are using vi, but the point is that the text config files are a
weak link in the security chain, at least weaker than the rest of it.
But, even if they do have root and use that to modify the text files,
that's still worse than just modifying the .so because an rpm upgrade
would not undo the damage so it's possible their subterfuge could exist
beyond measures that would otherwise render it null and void. If the
admin found out that someone had hacked root and was attempting to
re-lock down the machine, that could be problematic (yes, I know they
should really be reinstalling from scratch, but admins do what admins do
when the shit hits the fan).
And in the intervening years, I doubt the configurability of these text
files has been used by more people than I can count on one hand. And
those same people could, with no more than 5 minutes time, learn to
issue "make; make rpm; make install-rpm" in their git repo instead of
make install and get the same results with only slightly modified makefiles.
For all those reasons, I simply don't see the utility of those config
files being worth the added attack vector that they create.
> If an attacker can access the .driver files then they can access the
> .so, then the attacker can just replace libc.so, and game over.
>
> I think any possible attack avenue would have to involve setuid. Eg
> trick a setuid program using libibverbs to dlopen a user controlled .so.
>
> I don't have an avenue in mind though, that would require replacing
> /etc/ with something else, and AFAIK, the ability to do that would
> make other setuid programs like su and sudo insecure??
>
> Jason
>
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <a220db98-ebbf-5df4-e011-8804442796b8-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
@ 2016-09-04 21:40 ` Doug Ledford
[not found] ` <280b8620-0996-a9bc-dc93-bf5d710dd6de-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-09-04 21:40 UTC (permalink / raw)
To: Sagi Grimberg, Leon Romanovsky
Cc: Jason Gunthorpe, Christoph Hellwig, Steve Wise,
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1.1: Type: text/plain, Size: 825 bytes --]
On 9/4/2016 6:36 AM, Sagi Grimberg wrote:
>
>>> What I think it missing is a release schedule, stable fixes
>>> methodology and merge cycles. I think once we can agree on that
>>> a lot of the concerns will be addressed.
>>
>> This is exactly my point.
>> What do you think if we follow kernel release cycles and schedules? It
>> will give to everyone in RDMA world clear answer on WHEN question.
>
> That can work. But, I think that we need the stable fixes to be released
> more frequently (Ideally on-demand, but it might be too much of an
> overhead both to maintainers and users).
I don't think so. A regular release cadence to match the kernel, and on
demand hot fixes seems perfectly doable to me.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160901202110.GH20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-04 21:45 ` Doug Ledford
0 siblings, 0 replies; 174+ messages in thread
From: Doug Ledford @ 2016-09-04 21:45 UTC (permalink / raw)
To: Jason Gunthorpe, Steve Wise
Cc: 'Bart Van Assche', 'Sagi Grimberg',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 1927 bytes --]
On 9/1/2016 4:21 PM, Jason Gunthorpe wrote:
> On Thu, Sep 01, 2016 at 02:52:55PM -0500, Steve Wise wrote:
>>>>
>>>> So we have nominations for
>>>>
>>>> srptools http://git.openfabrics.org/?p=~bvanassche/srptools.git/.git.
>>>> perftest git://git.openfabrics.org/~grockah/perftest.git master
>>>
>>> I would drop perftest out. Here's why. I like the idea that this
>>> package is for software that interacts with the kernel directly. It
>>> needs to, in some way, involve itself with the kernel char interface or
>>> with the kernel netlink interface. So far, everything meets that
>>> critera. Perftest does not. So, in the same fashion as libfabrics and
>>> fabtests, I would leave perftest out, but that isn't to say a separate
>>> package that pulled together various testing apps for RDMA could be
>>> created too.
>>>
>>
>> I see your point. That is fine with me.
>
> I'm happy either way, but I will point out that libibverbs and
> librdmacm sources contains various things similar to perftest (eg the
> pingpong stuff, _bw, etc).
>
> If we were to merge perftest I'd probably aim to consolidate all of
> those similar examples/tests/etc under one directory in the source
> tree.
>
> I'd cast perftest and related as diagnostic tools to help users
> validate verbs hardware is working as expected, so still under the
> plumbing umbrella.
>
> Jason
>
I can see your point. Maybe start with things as they are, then in some
subsequent work we consolidate all of the example programs from
libibverbs/librdmacm into one place, then we look at what programs could
possibly be folded in too (perftest would probably work, but for
instance, qperf works on tcp and other things not-rdma and is generally
useful even without rdma, so I don't know that I would fold it in).
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160902233231.GA26309-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-03 0:10 ` Bart Van Assche
@ 2016-09-04 21:47 ` Doug Ledford
1 sibling, 0 replies; 174+ messages in thread
From: Doug Ledford @ 2016-09-04 21:47 UTC (permalink / raw)
To: Jason Gunthorpe, Steve Wise
Cc: 'Bart Van Assche', 'Sagi Grimberg',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1.1: Type: text/plain, Size: 289 bytes --]
On 9/2/2016 7:32 PM, Jason Gunthorpe wrote:
> We will need to get a systemd service file for srp_daemon,
We obviously have a working systemd file for anything that currently exists.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160904055441.GI21847-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-04 23:55 ` Jason Gunthorpe
[not found] ` <20160904235555.GA21542-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-04 23:55 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Bart Van Assche, Steve Wise, 'Sagi Grimberg',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Sun, Sep 04, 2016 at 08:54:41AM +0300, Leon Romanovsky wrote:
> On Fri, Sep 02, 2016 at 11:12:22PM -0600, Jason Gunthorpe wrote:
> > On Fri, Sep 02, 2016 at 05:10:45PM -0700, Bart Van Assche wrote:
> >
> > So I added opensuse 13.2 and 42.1 to the list of docker container
> > builders and the simple build looks like it runs OK.
>
> Are you running standard docker containers or build them by yourself?
> Can you add scripts to run containers to your rdma-plumbers repo? So it
> will be much easier to see/debug build issues on different platforms.
I mentioned this in my first email, but here is more details.
The tooling branch contains all the scripting I used to build and test
this thing. The docker/ directory has all the docker files and the
script to run them.
https://github.com/jgunthorpe/rdma-plumbing/tree/tooling/docker
The docker script is something I've used for awhile in other places,
there are others around as well that are similar.. The basic usage is
like this:
# Download docker base images and run all docker files
# Do once.
$ docker/do_docker.py build-images --env all
# Run 'make' inside the container using the current source tree
# exactly as is. Directs the build to a build-fc24 output directory
$ docker/do_docker.py make fc24
# Build a package. This runs 'git archive', imports the archive into
# the container, transfers the spec file, fusses with the container,
# runs rpmbuild/dpkg-buildpkg, then copies the rpms back out. Note
# that changes must be checked in to have any impact.
$ docker/do_docker.py pkg fc24
Folks can decide how much of this stuff should go on into the main
repository later on..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <280b8620-0996-a9bc-dc93-bf5d710dd6de-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-09-05 1:51 ` Jason Gunthorpe
2016-09-05 5:29 ` Leon Romanovsky
1 sibling, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-05 1:51 UTC (permalink / raw)
To: Doug Ledford
Cc: Sagi Grimberg, Leon Romanovsky, Christoph Hellwig, Steve Wise,
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Sun, Sep 04, 2016 at 05:40:48PM -0400, Doug Ledford wrote:
> On 9/4/2016 6:36 AM, Sagi Grimberg wrote:
> >
> >>> What I think it missing is a release schedule, stable fixes
> >>> methodology and merge cycles. I think once we can agree on that
> >>> a lot of the concerns will be addressed.
> >>
> >> This is exactly my point.
> >> What do you think if we follow kernel release cycles and schedules? It
> >> will give to everyone in RDMA world clear answer on WHEN question.
> >
> > That can work. But, I think that we need the stable fixes to be released
> > more frequently (Ideally on-demand, but it might be too much of an
> > overhead both to maintainers and users).
>
> I don't think so. A regular release cadence to match the kernel, and on
> demand hot fixes seems perfectly doable to me.
It would be good to ask the distros what they would use. It makes very
little sense to make releases that people are not interested in.
Following the kernel makes a lot of sense as a starting
point. Inviting the distros to co-maintain their stable branches
publicly might also be sensible..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <9efe8c8f-40e2-b016-9a1e-4770298b9068-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-09-05 2:34 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-05 2:34 UTC (permalink / raw)
To: Doug Ledford
Cc: ira.weiny, Woodruff, Robert J, Leon Romanovsky, Steve Wise,
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong
On Sun, Sep 04, 2016 at 05:38:45PM -0400, Doug Ledford wrote:
> >> 1) The override directory needs to be a fixed place.
> >
> > /etc/libibverbs.d/*.driver is the standard drop in place we used, and is
> > already used by every provider driver.
>
> I meant the .so's override directory. I'm assuming the actual .so name
> for an override driver will have the same name as the default .so, so
> you need a second directory. I would make that directory a fixed,
> standard location.
.so override? Where did that come? I'm not proposing that..
I would not give them the same name either, we don't need to because
the .driver file lets us override, that is the whole point.
> >> 2) The driver files need to only allow names. The absolute path patch
> >> sounds like an immediate security issue.
> >
> > The patch for this has been in for years now.
>
> It might be worth removing it, or at least analyzing it in more detail...
Well, lets have some detail, I don't see anything that would warrant a
security concern.
> It won't break biarch. You can't load a 32bit .so with a 64bit
> libibverbs and vice versa, so you can put the .so library path into your
> binary based upon arch. I would do this in preference to libdl searches.
I generally dislike to hardcode paths like that, but sure, we could
do something like that.
> It's not just the permissions to modify, it's the file's default
> context. Many files in SELinux parlance inherit their default context
> based upon their location. If you want to have a specific
> rdma_driver_t
Why would I need a rdma_drver_t label? Loading the driver .so or the
.driver file is not a security sensitive operation.
I don't know if I've ever heard of using selinux to forbid running
unprivileged binaries?? Is that really a thing? Doesn't just running
them from your home dir trivially defeat that?
> context, you would need a directory specifically for them so you can
> have an SELinux inheritance rule that sets the driver's context.
The .driver doesn't really change anything. If selinux has arranged
things so libibverbs will only load labeled plugins, then the
driver.so still has to carry that label, nothing has really changed by
adding the indirection through the .driver file.
If an attacker can manipulate selinux labels then all is lost and the
.driver file is not a concern.
> rpm, then the new file is saved as <filename>.rpmnew. My comment above
> is that in order to support modifying those driver files and not having
> those modifications get wiped out on upgrade, the config files must be
> marked as %config(noreplace) and that means we will preserve
> changes.
AFAIK, %config leaves the user's file alone *unless* the file in the
copy in the .rpm has been updated (other wise config files are
useless). Since we never change the .driver file %config and
%config(noreplace) are essentially identical for our purposes. A user
modified .driver file will not be replaced if the .rpm is upgraded or
re-installed, which is the desired behavior.
> >> anywhere. And then you have something like opensm being run as root and
> >> loading up this nefarious driver from wherever. It's a big security issue.
> >
> > This makes no sense. As above, access to the .driver files must
> > require the same privledge to write as write to the .so libraries.
>
> A text config file is easier to manage a hack on that a .so. If
> your
Eh? Any change to the .driver file must be matched with creating a
nefarious .so. I don't see how this makes it any easier.
> library simply doesn't read any text config files and instead has
> SELinux secured .so's in a well protected place, that is more
> secure.
Don't see it. Your definition of 'secure' is really strange.
> Yes, you would need root in order to modify the driver config text files
> if you are using vi, but the point is that the text config files are a
> weak link in the security chain, at least weaker than the rest of it.
I've never seen security evaluated this way.
> But, even if they do have root and use that to modify the text files,
> that's still worse than just modifying the .so because an rpm upgrade
> would not undo the damage so it's possible their subterfuge could
> exist
See above about %config..
> beyond measures that would otherwise render it null and void. If the
> admin found out that someone had hacked root and was attempting to
> re-lock down the machine, that could be problematic (yes, I know they
> should really be reinstalling from scratch, but admins do what admins do
> when the shit hits the fan).
Again, never seen security evaluated this way.
A compromized machine must be wipe-installed.
You could apply all your arguments to many files in /etc. For instance
why do you think the .driver bad but /etc/ld.so.conf.d/ is OK?
> And in the intervening years, I doubt the configurability of these text
> files has been used by more people than I can count on one hand.
Uh, look in libibverbs/debian, it is used by the Debian
packaging. Every single Debian user relies on this feature.
> For all those reasons, I simply don't see the utility of those config
> files being worth the added attack vector that they create.
Well, I agree with getting rid of the default .driver files, just for
different reasons..
I'd keep them for vendor overrides, which really is their designed
function anyhow.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <BLUPR02MB16836859F638150FF6330A0A81E40-Y8PPn9RqzNfZ9ihocuPUdanrV9Ap65cLvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
@ 2016-09-05 4:10 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-05 4:10 UTC (permalink / raw)
To: Bart Van Assche
Cc: Steve Wise, 'Sagi Grimberg', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Sat, Sep 03, 2016 at 02:08:24PM +0000, Bart Van Assche wrote:
> On my development system I run openSuSE Tumbleweed, a rolling release. I
> update it every now and then by running "zypper dist-upgrade". Some of
> our production systems run SLES 12 SP2; others run RHEL 6 or RHEL 7.
Okay, this is what I came up with. Not very pretty, but suse and rh
have different %cmake macros.. :|
Docker says it works on tumbleweed, os42.1, os13.2, fc24, c7, c6 -
which seems like enough :|
Name: rdma-plumbing
Version: 1
Release: 1%{?dist}
Summary: Userspace components for the Linux Kernel\'s drivers/infiniband stack
License: GPLv2 or BSD
Url: http://openfabrics.org/
Source: rdma-plumbing-%{version}.tgz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
BuildRequires: binutils
BuildRequires: cmake >= 2.8.11
BuildRequires: gcc
BuildRequires: pkgconfig
BuildRequires: pkgconfig(libnl-3.0)
BuildRequires: pkgconfig(libnl-route-3.0)
BuildRequires: valgrind-devel
# Since we recommend developers use Ninja, so should packagers, for consistency.
%define CMAKE_FLAGS %{nil}
%if 0%{?suse_version}
# SuSE releases have it, and sometime around cmake 3.3.2-1.2 the macros learned to use it.
BuildRequires: ninja,make
%define __builder ninja
# cmake_install,make_jobs is specified by opensuse
%else
%if 0%{?fedora} >= 23
# Ninja was introduced in FC23
BuildRequires: ninja-build
%define CMAKE_FLAGS -GNinja
%define make_jobs ninja -v %{?_smp_mflags}
%define cmake_install DESTDIR=%{buildroot} ninja-build install
%else
# Fallback to make otherwise
BuildRequires: make
%define make_jobs make -v %{?_smp_mflags}
%define cmake_install DESTDIR=%{buildroot} make install
%endif
%endif
%description
Temporary packaging
This is a simple example without the split sub packages to get things started.
%prep
%setup
%build
# Detect if systemd is supported on this system
%if 0%{?_unitdir:1}
%define my_unitdir %{_unitdir}
%else
%define my_unitdir /tmp/
%endif
# Pass all of the rpm paths directly to GNUInstallDirs and our other defines.
%cmake %{CMAKE_FLAGS} \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_BINDIR:PATH=%{_bindir} \
-DCMAKE_INSTALL_SBINDIR:PATH=%{_sbindir} \
-DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \
-DCMAKE_INSTALL_LIBEXECDIR:PATH=%{_libexecdir} \
-DCMAKE_INSTALL_LOCALSTATEDIR:PATH=%{_localstatedir} \
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=%{_sharedstatedir} \
-DCMAKE_INSTALL_INCLUDEDIR:PATH=%{_includedir} \
-DCMAKE_INSTALL_INFODIR:PATH=%{_infodir} \
-DCMAKE_INSTALL_MANDIR:PATH=%{_mandir} \
-DCMAKE_INSTALL_SYSCONFDIR:PATH=%{_sysconfdir} \
-DCMAKE_INSTALL_SYSTEMD_SERVICEDIR:PATH=%{my_unitdir} \
-DCMAKE_INSTALL_INITDDIR:PATH=%{_initrddir}
%make_jobs
%install
%cmake_install
%if 0%{?_unitdir:1}
rm -rf %{buildroot}/%{_initrddir}/
%else
rm -rf %{buildroot}/%{my_unitdir}/
%endif
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
%files
%doc %{_mandir}/man*/*
%{_bindir}/*
%{_includedir}/*
%{_libdir}/lib*
%{_libdir}/rsocket/*
%{_sbindir}/*
%if 0%{?_unitdir:1}
%{_unitdir}/*
%else
%config %{_initrddir}/*
%endif
%config %{_sysconfdir}/iwpmd.conf
%config %{_sysconfdir}/srp_daemon.conf
%config %{_sysconfdir}/libibverbs.d/*
%config %{_sysconfdir}/logrotate.d/srp_daemon
%{_sysconfdir}/modprobe.d/*
%config %{_sysconfdir}/rsyslog.d/srp_daemon.conf
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <280b8620-0996-a9bc-dc93-bf5d710dd6de-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-05 1:51 ` Jason Gunthorpe
@ 2016-09-05 5:29 ` Leon Romanovsky
1 sibling, 0 replies; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-05 5:29 UTC (permalink / raw)
To: Doug Ledford
Cc: Sagi Grimberg, Jason Gunthorpe, Christoph Hellwig, Steve Wise,
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
On Sun, Sep 04, 2016 at 05:40:48PM -0400, Doug Ledford wrote:
> On 9/4/2016 6:36 AM, Sagi Grimberg wrote:
> >
> >>> What I think it missing is a release schedule, stable fixes
> >>> methodology and merge cycles. I think once we can agree on that
> >>> a lot of the concerns will be addressed.
> >>
> >> This is exactly my point.
> >> What do you think if we follow kernel release cycles and schedules? It
> >> will give to everyone in RDMA world clear answer on WHEN question.
> >
> > That can work. But, I think that we need the stable fixes to be released
> > more frequently (Ideally on-demand, but it might be too much of an
> > overhead both to maintainers and users).
>
> I don't think so. A regular release cadence to match the kernel, and on
> demand hot fixes seems perfectly doable to me.
It is a good starting point and in addition to releases we would like to
see the same fast piece of accepting new code into vendor specific
user space drivers. It is hard to get rid of feelings for possible long
submission queues.
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG Key ID: 0E572FDD
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160904235555.GA21542-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-05 12:48 ` Leon Romanovsky
[not found] ` <20160905124802.GX21847-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-05 12:48 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Bart Van Assche, Steve Wise, 'Sagi Grimberg',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]
On Sun, Sep 04, 2016 at 05:55:55PM -0600, Jason Gunthorpe wrote:
> On Sun, Sep 04, 2016 at 08:54:41AM +0300, Leon Romanovsky wrote:
> > On Fri, Sep 02, 2016 at 11:12:22PM -0600, Jason Gunthorpe wrote:
> > > On Fri, Sep 02, 2016 at 05:10:45PM -0700, Bart Van Assche wrote:
> > >
> > > So I added opensuse 13.2 and 42.1 to the list of docker container
> > > builders and the simple build looks like it runs OK.
> >
> > Are you running standard docker containers or build them by yourself?
> > Can you add scripts to run containers to your rdma-plumbers repo? So it
> > will be much easier to see/debug build issues on different platforms.
>
> I mentioned this in my first email, but here is more details.
>
> The tooling branch contains all the scripting I used to build and test
> this thing. The docker/ directory has all the docker files and the
> script to run them.
>
> https://github.com/jgunthorpe/rdma-plumbing/tree/tooling/docker
>
> The docker script is something I've used for awhile in other places,
> there are others around as well that are similar.. The basic usage is
> like this:
>
> # Download docker base images and run all docker files
> # Do once.
> $ docker/do_docker.py build-images --env all
>
> # Run 'make' inside the container using the current source tree
> # exactly as is. Directs the build to a build-fc24 output directory
> $ docker/do_docker.py make fc24
>
> # Build a package. This runs 'git archive', imports the archive into
> # the container, transfers the spec file, fusses with the container,
> # runs rpmbuild/dpkg-buildpkg, then copies the rpms back out. Note
> # that changes must be checked in to have any impact.
> $ docker/do_docker.py pkg fc24
>
> Folks can decide how much of this stuff should go on into the main
> repository later on..
I completely missed that tooling branch. It looks like it misses the
Debian image.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160905124802.GX21847-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-05 17:46 ` Jason Gunthorpe
[not found] ` <20160905174636.GC14403-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-05 17:46 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Bart Van Assche, Steve Wise, 'Sagi Grimberg',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Mon, Sep 05, 2016 at 03:48:02PM +0300, Leon Romanovsky wrote:
> > Folks can decide how much of this stuff should go on into the main
> > repository later on..
>
> I completely missed that tooling branch. It looks like it misses the
> Debian image.
Only 'make' works for Debian. There is no .deb packaging yet.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <4b791de5-0d6e-fd94-8a31-2fe833ca72db-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-04 8:35 ` Leon Romanovsky
@ 2016-09-06 7:01 ` Christoph Hellwig
[not found] ` <20160906070102.GA23248-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-06 19:38 ` Jason Gunthorpe
2 siblings, 1 reply; 174+ messages in thread
From: Christoph Hellwig @ 2016-09-06 7:01 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Jason Gunthorpe, Leon Romanovsky, Christoph Hellwig, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Sun, Sep 04, 2016 at 11:18:02AM +0300, Sagi Grimberg wrote:
> I think that having a maintainer per provider makes perfect sense
> and as long as you Jason (or anyone else) are committed to merging it
> all together and produce standard releases we are pretty much set.
>
> What I think it missing is a release schedule, stable fixes
> methodology and merge cycles. I think once we can agree on that
> a lot of the concerns will be addressed.
So let's keep the maintainers as-is, e.g. each previous project
keepts it's own maintainer similar to driver maintainers in the kernel.
We'll add Jason as a global maintainer for the build system or any
non-controverial fixes and we should be much better setup than the
current situation.
Combine that with kernel-like major releases plus minor release on
demand and we should have a winning setup.
Now we just need to bikeshed on a good name for the repo, because
honestly rdma-plumbing sucks as a name :)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160906070102.GA23248-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2016-09-06 8:50 ` Sagi Grimberg
[not found] ` <6d47ca96-25eb-8358-879d-fc646ddda9cb-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-06 18:34 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-06 8:50 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jason Gunthorpe, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
>> I think that having a maintainer per provider makes perfect sense
>> and as long as you Jason (or anyone else) are committed to merging it
>> all together and produce standard releases we are pretty much set.
>>
>> What I think it missing is a release schedule, stable fixes
>> methodology and merge cycles. I think once we can agree on that
>> a lot of the concerns will be addressed.
>
> So let's keep the maintainers as-is, e.g. each previous project
> keepts it's own maintainer similar to driver maintainers in the kernel.
> We'll add Jason as a global maintainer for the build system or any
> non-controverial fixes and we should be much better setup than the
> current situation.
>
> Combine that with kernel-like major releases plus minor release on
> demand and we should have a winning setup.
>
> Now we just need to bikeshed on a good name for the repo, because
> honestly rdma-plumbing sucks as a name :)
librdma maybe?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <6d47ca96-25eb-8358-879d-fc646ddda9cb-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
@ 2016-09-06 11:07 ` Leon Romanovsky
[not found] ` <20160906110729.GM21847-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-06 11:07 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Christoph Hellwig, Jason Gunthorpe, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
On Tue, Sep 06, 2016 at 11:50:54AM +0300, Sagi Grimberg wrote:
>
> librdma maybe?
It is not exactly library.
Maybe rdma-bundle?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (16 preceding siblings ...)
2016-09-01 15:24 ` Sagi Grimberg
@ 2016-09-06 13:59 ` Hal Rosenstock
[not found] ` <bb889a58-331c-8ba8-920d-e3a79072dce4-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-09-13 16:28 ` Hefty, Sean
18 siblings, 1 reply; 174+ messages in thread
From: Hal Rosenstock @ 2016-09-06 13:59 UTC (permalink / raw)
To: Jason Gunthorpe, Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Mike Marciniszyn, Moni Shoua, Sean Hefty,
Steve Wise, Tatyana Nikolova, Vladimir Sokolovsky, Yishai Hadas
On 8/22/2016 2:13 PM, Jason Gunthorpe wrote:
> Hello Everyone,
>
> Here is the patch series for the consolidation. This is based on the special
> merge commit created by the buildlib/make-merge.py script. See my prior
> message (http://www.spinics.net/lists/linux-rdma/msg39026.html) for details.
>
> The first 7 patches change/fix various things in the original packages to
> build consistently, patch 8 has cmake and all the auto* co-exist, and can be
> used to do build compares (see buildlib/compare-build.py)
>
> The next batch of patches removes the old build stuff, packaging, merges
> COPYING files and lightly simplifies the directory structure.
>
> https://github.com/jgunthorpe/rdma-plumbing
>
> This has been rebased since my last posting with feedback from Steve.
>
> The following 15 repositories were pulled together.
>
> libcxgb3 git://git.openfabrics.org/~swise/libcxgb3.git 0de0392268af3a657b329874b63b6ee827109508
> libcxgb4 git://git.openfabrics.org/~swise/libcxgb4.git 15d3253dc814da28e2b93ed02a8e9a96d97f20ae
> libhfi1verbs https://github.com/01org/opa-libhfi1verbs.git 377b68888a0b885fc2a44ddf7a2ec33f2fcf217b
> libi40iw git://git.openfabrics.org/~tnikolova/libi40iw/.git 9d35609f79d6a235e23182e9ceadf3605b2682da
> libibcm git://git.openfabrics.org/~shefty/libibcm.git b04920e8bfe0689a2fe67815321dcf646fd48a7e
> libibumad git://git.openfabrics.org/~halr/libibumad.git ecda3a56b18c6a2845f3d966f8b8061941f5d447
> libibverbs git://git.kernel.org/pub/scm/libs/infiniband/libibverbs.git 0be978ea2bfaf203c35334b090bddb280de62611
> libipathverbs https://github.com/01org/libipathverbs.git 8291d485f3a5544b43974e7be88f3646f35ae07c
> libmlx4 git://git.openfabrics.org/~yishaih/libmlx4.git 162f948c4e04753a15cfb7afcdf6219dbe0bc31e
> libmlx5 git://git.openfabrics.org/~yishaih/libmlx5.git f23f9aa7b9033cd8ebbd58d67d65e9b81d0525fa
> libmthca git://git.kernel.org/pub/scm/libs/infiniband/libmthca.git 6f4dd7451ddef120247e13fa6cb8e1df69c3ddf9
> libnes git://git.openfabrics.org/~tnikolova/libnes/.git 7dc7cf2474612ec909bff251096ca2aefa9cddf1
> libocrdma git://git.openfabrics.org/~emulex/libocrdma.git 41f6bbb3fe8129678c233da439d872b3fe9f75dc
> librdmacm git://git.openfabrics.org/~shefty/librdmacm.git 032bbe60ad32d59004447e03061a9f6d632cc55f
> librxe https://github.com/SoftRoCE/librxe-dev.git 227e3c49b6e423c066e1e1887fe30c8261f63cbd
It would be nice if history from the original repos was
preserved/propagated into this combined repo. Is there a reason that
wasn't done ?
> Steve suggests that iwpm be included as well, which makes sense..
>
> My hope is that Doug will step up as the unified maintainer, with a process
> similar to the kernel. Most of the libraries are unchanging/unmaintained/dead.
What is the anticipated process here ? Will the submaintainers need to
go through the uber-maintainer ?
-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <bb889a58-331c-8ba8-920d-e3a79072dce4-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2016-09-06 16:37 ` Jason Gunthorpe
[not found] ` <20160906163708.GA3862-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-06 16:37 UTC (permalink / raw)
To: Hal Rosenstock
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Mike Marciniszyn, Moni Shoua, Sean Hefty, Steve Wise,
Tatyana Nikolova, Vladimir Sokolovsky, Yishai Hadas
On Tue, Sep 06, 2016 at 09:59:48AM -0400, Hal Rosenstock wrote:
> It would be nice if history from the original repos was
> preserved/propagated into this combined repo. Is there a reason that
> wasn't done ?
Of course this was done. I talked about it at length in the first
email. What are you seeing that makes you think otherwise?
Check it out in action here:
https://github.com/jgunthorpe/rdma-plumbing/blame/master/libibumad/src/umad.c
The blame is going back through the entire available git history.
Note that git has all sorts of weirdness with rename handling so this
doesn't always work so well.. eg github's single file history doesn't
work, but 'git log --follow' mostly does.
> > Steve suggests that iwpm be included as well, which makes sense..
> >
> > My hope is that Doug will step up as the unified maintainer, with a process
> > similar to the kernel. Most of the libraries are unchanging/unmaintained/dead.
>
> What is the anticipated process here ? Will the submaintainers need to
> go through the uber-maintainer ?
I think Doug and Leon are working that out somewhere in this thread.
There is a range of options projects tend to use:
- Send a patch, ack other peoples patches
- Send a pull request
- Have a 'commit bit' and push directly to the master repo
umad changes so little that the first is probably the least work
option for you.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160906163708.GA3862-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-06 17:05 ` Hal Rosenstock
[not found] ` <a815efb1-424f-10a6-468e-d94f420a73be-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Hal Rosenstock @ 2016-09-06 17:05 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Mike Marciniszyn, Moni Shoua, Sean Hefty, Steve Wise,
Tatyana Nikolova, Vladimir Sokolovsky, Yishai Hadas
On 9/6/2016 12:37 PM, Jason Gunthorpe wrote:
> On Tue, Sep 06, 2016 at 09:59:48AM -0400, Hal Rosenstock wrote:
>
>> It would be nice if history from the original repos was
>> preserved/propagated into this combined repo. Is there a reason that
>> wasn't done ?
>
> Of course this was done. I talked about it at length in the first
> email. What are you seeing that makes you think otherwise?
I was basing my comment based on git log not including all the commits.
> Check it out in action here:
>
> https://github.com/jgunthorpe/rdma-plumbing/blame/master/libibumad/src/umad.c
>
> The blame is going back through the entire available git history.
git blame seems to work fine.
> Note that git has all sorts of weirdness with rename handling so this
> doesn't always work so well.. eg github's single file history doesn't
> work, but 'git log --follow' mostly does.
I see git log doesn't show older commits but you can get them with
--follow one file at a time.
-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <a815efb1-424f-10a6-468e-d94f420a73be-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2016-09-06 18:15 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-06 18:15 UTC (permalink / raw)
To: Hal Rosenstock
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Mike Marciniszyn, Moni Shoua, Sean Hefty, Steve Wise,
Tatyana Nikolova, Vladimir Sokolovsky, Yishai Hadas
On Tue, Sep 06, 2016 at 01:05:33PM -0400, Hal Rosenstock wrote:
> On 9/6/2016 12:37 PM, Jason Gunthorpe wrote:
> > On Tue, Sep 06, 2016 at 09:59:48AM -0400, Hal Rosenstock wrote:
> >
> >> It would be nice if history from the original repos was
> >> preserved/propagated into this combined repo. Is there a reason that
> >> wasn't done ?
> >
> > Of course this was done. I talked about it at length in the first
> > email. What are you seeing that makes you think otherwise?
>
> I was basing my comment based on git log not including all the commits.
??
$ git log | grep -i commit | wc -l
2421
> > Note that git has all sorts of weirdness with rename handling so this
> > doesn't always work so well.. eg github's single file history doesn't
> > work, but 'git log --follow' mostly does.
>
> I see git log doesn't show older commits but you can get them with
> --follow one file at a time.
Right, you cannot do 'git log --follow libibumad/' for instance, that
is a documented limitation of git.
You can get around this manually...
$ git log libibumad/ | grep -i commit
[..]
7a47c9614206e790e2e504c22fc698fe96e1bb5b
$ git log 7a47c9614206e790e2e504c22fc698fe96e1bb5b
[now you see the natural commit list from the original libibumad]
The repository is constructed properly, but git's rename handling does
not do everything you might want.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160906070102.GA23248-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-06 8:50 ` Sagi Grimberg
@ 2016-09-06 18:34 ` Jason Gunthorpe
[not found] ` <20160906183405.GA27914-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-06 18:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Sagi Grimberg, Leon Romanovsky, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Tue, Sep 06, 2016 at 12:01:02AM -0700, Christoph Hellwig wrote:
> On Sun, Sep 04, 2016 at 11:18:02AM +0300, Sagi Grimberg wrote:
> > I think that having a maintainer per provider makes perfect sense
> > and as long as you Jason (or anyone else) are committed to merging it
> > all together and produce standard releases we are pretty much set.
> >
> > What I think it missing is a release schedule, stable fixes
> > methodology and merge cycles. I think once we can agree on that
> > a lot of the concerns will be addressed.
>
> So let's keep the maintainers as-is, e.g. each previous project
> keepts it's own maintainer similar to driver maintainers in the
> kernel.
This is certainly what I imagined. Nobody else has the domain
expertise for these sub components.
However, there is a lot of work just to keep everything ticking over,
compilers change, build tooling changes, distros need hand holding,
boring patches need accepting. That is where all maintainers should see
value in this approach.
> We'll add Jason as a global maintainer for the build system or any
> non-controverial fixes and we should be much better setup than the
> current situation.
I was hoping a team including Doug would handle the general patch
stream. Most of the patch flow today is for libibverbs and related
anyhow. If Leon wants to handle the boring patches and provider pulls
then that seems like a good combination.
> Combine that with kernel-like major releases plus minor release on
> demand and we should have a winning setup.
I think the release cadence should be driven more by the distros, but
following the kernel cadence is a sane place to start.
Not much point in making a release if nobody is out there wanting to
use it. I expect the distros will want to go to a more stable
maintenance footing so we many want to offer to co-maintain a public
LTS branch...
> Now we just need to bikeshed on a good name for the repo, because
> honestly rdma-plumbing sucks as a name :)
Let the painting commence!
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160826154206.GK1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-26 22:27 ` Jason Gunthorpe
@ 2016-09-06 19:26 ` Jason Gunthorpe
1 sibling, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-06 19:26 UTC (permalink / raw)
To: Jarod Wilson
Cc: Doug Ledford, Steve Wise, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
'Devesh Sharma', 'Hal Rosenstock',
'Mike Marciniszyn', 'Moni Shoua',
'Sean Hefty', 'Tatyana Nikolova',
'Vladimir Sokolovsky', 'Yishai Hadas'
On Fri, Aug 26, 2016 at 11:42:06AM -0400, Jarod Wilson wrote:
> > Would you help making a spec file that is close to what you
> > could use in the distro? I don't really care if it is stored in the
> > package or stored inside RH, but we need to get one made.
>
> Sure. It would probably be something to route through Fedora first though,
> and I don't own all the packages this would encompass in Fedora, but could
> certainly round a few people up and help out.
I think things are now in a state where it makes sense to start
looking at this.
As Doug has mentioned there are several things in the current rpm
packaging that would be good to make it upstream.
I also need some help to compile-test this on more architectures.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <4b791de5-0d6e-fd94-8a31-2fe833ca72db-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-04 8:35 ` Leon Romanovsky
2016-09-06 7:01 ` Christoph Hellwig
@ 2016-09-06 19:38 ` Jason Gunthorpe
2 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-06 19:38 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Leon Romanovsky, Christoph Hellwig, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Sun, Sep 04, 2016 at 11:18:02AM +0300, Sagi Grimberg wrote:
> I think that having a maintainer per provider makes perfect sense
> and as long as you Jason (or anyone else) are committed to merging it
> all together and produce standard releases we are pretty much set.
Just to be very clear: the merge I've performed will not be
ongoing - at some point we need a flag day where the 17 original git
repositories are fully retired. There will be a final merge+rebase and
then it will have to stop.
There are now 54 patches on top of that merge and it is not
feasible to keep all these plates spinning long term.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160906183405.GA27914-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-07 6:56 ` Leon Romanovsky
2016-09-07 8:21 ` Sagi Grimberg
1 sibling, 0 replies; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-07 6:56 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Christoph Hellwig, Sagi Grimberg, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 3219 bytes --]
On Tue, Sep 06, 2016 at 12:34:05PM -0600, Jason Gunthorpe wrote:
> On Tue, Sep 06, 2016 at 12:01:02AM -0700, Christoph Hellwig wrote:
> > On Sun, Sep 04, 2016 at 11:18:02AM +0300, Sagi Grimberg wrote:
> > > I think that having a maintainer per provider makes perfect sense
> > > and as long as you Jason (or anyone else) are committed to merging it
> > > all together and produce standard releases we are pretty much set.
> > >
> > > What I think it missing is a release schedule, stable fixes
> > > methodology and merge cycles. I think once we can agree on that
> > > a lot of the concerns will be addressed.
> >
> > So let's keep the maintainers as-is, e.g. each previous project
> > keepts it's own maintainer similar to driver maintainers in the
> > kernel.
>
> This is certainly what I imagined. Nobody else has the domain
> expertise for these sub components.
>
> However, there is a lot of work just to keep everything ticking over,
> compilers change, build tooling changes, distros need hand holding,
> boring patches need accepting. That is where all maintainers should see
> value in this approach.
>
> > We'll add Jason as a global maintainer for the build system or any
> > non-controverial fixes and we should be much better setup than the
> > current situation.
>
> I was hoping a team including Doug would handle the general patch
> stream. Most of the patch flow today is for libibverbs and related
> anyhow. If Leon wants to handle the boring patches and provider pulls
> then that seems like a good combination.
It is not that I'm over-excited about it, just I think that someone needs
to do it to keep RDMA stack moving forward. I personally see the whole RDMA
stack as one entity and don't want to separate it to kernel vs. user.
>
> > Combine that with kernel-like major releases plus minor release on
> > demand and we should have a winning setup.
>
> I think the release cadence should be driven more by the distros, but
> following the kernel cadence is a sane place to start.
>
> Not much point in making a release if nobody is out there wanting to
> use it. I expect the distros will want to go to a more stable
> maintenance footing so we many want to offer to co-maintain a public
> LTS branch...
Release -> put a tag every X-days. For example Linus's tag will close
patch acceptance and 1-2 weeks after that, new tag will be added. In such way
everyone will know exactly what and when new version will be available.
Changelog can be generated from git history, participation in
rawhide/testing/tumblweed will ensure that packages are constantly
built.
At this point of time I don't see any reasons to manage stable branches,
it is much easier and convenient to ensure that master is always
buildable and ready to ship.
It will be worth to make a split for libibverbs2.0 when we will work on
ABI.
>
> > Now we just need to bikeshed on a good name for the repo, because
> > honestly rdma-plumbing sucks as a name :)
>
> Let the painting commence!
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160906183405.GA27914-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-07 6:56 ` Leon Romanovsky
@ 2016-09-07 8:21 ` Sagi Grimberg
[not found] ` <cd964412-11f3-d1ca-ef76-830a24cb8e68-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-07 8:21 UTC (permalink / raw)
To: Jason Gunthorpe, Christoph Hellwig
Cc: Leon Romanovsky, Steve Wise, 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
>>> What I think it missing is a release schedule, stable fixes
>>> methodology and merge cycles. I think once we can agree on that
>>> a lot of the concerns will be addressed.
>>
>> So let's keep the maintainers as-is, e.g. each previous project
>> keepts it's own maintainer similar to driver maintainers in the
>> kernel.
>
> This is certainly what I imagined. Nobody else has the domain
> expertise for these sub components.
>
> However, there is a lot of work just to keep everything ticking over,
> compilers change, build tooling changes, distros need hand holding,
> boring patches need accepting. That is where all maintainers should see
> value in this approach.
Fully agree.
>> We'll add Jason as a global maintainer for the build system or any
>> non-controverial fixes and we should be much better setup than the
>> current situation.
>
> I was hoping a team including Doug would handle the general patch
> stream. Most of the patch flow today is for libibverbs and related
> anyhow. If Leon wants to handle the boring patches and provider pulls
> then that seems like a good combination.
I actually think Yishai would be perfect for this job (should he accept
it). Yishai has been feeding Doug from his libibverbs repo for some time
now and I've been using it for tech previews.
I think that Yishai and Doug maintaining libibverbs as a team would be
great. Having said that, we'll need to understand if they are fine with
it.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <cd964412-11f3-d1ca-ef76-830a24cb8e68-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
@ 2016-09-07 13:14 ` Yishai Hadas
[not found] ` <924d7775-0d24-e1ca-b0ee-226df053089a-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Yishai Hadas @ 2016-09-07 13:14 UTC (permalink / raw)
To: Sagi Grimberg, 'Doug Ledford'
Cc: Jason Gunthorpe, Christoph Hellwig, Leon Romanovsky, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On 9/7/2016 11:21 AM, Sagi Grimberg wrote:
> I actually think Yishai would be perfect for this job (should he accept
> it). Yishai has been feeding Doug from his libibverbs repo for some time
> now and I've been using it for tech previews.
Thanks Sagi for your feedback, it's really appreciated.
> I think that Yishai and Doug maintaining libibverbs as a team would be
> great. Having said that, we'll need to understand if they are fine with
> it.
Yes, I'm fine with taking responsibility and maintain libibverbs.
I believe that it will reduce burden from Doug and escalate the
development/acceptance process in the user space area.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <924d7775-0d24-e1ca-b0ee-226df053089a-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2016-09-07 15:58 ` Jason Gunthorpe
[not found] ` <20160907155849.GE2878-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-07 15:58 UTC (permalink / raw)
To: Yishai Hadas
Cc: Sagi Grimberg, 'Doug Ledford',
Christoph Hellwig, Leon Romanovsky, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Wed, Sep 07, 2016 at 04:14:37PM +0300, Yishai Hadas wrote:
> >I think that Yishai and Doug maintaining libibverbs as a team would be
> >great. Having said that, we'll need to understand if they are fine with
> >it.
>
> Yes, I'm fine with taking responsibility and maintain libibverbs.
> I believe that it will reduce burden from Doug and escalate the
> development/acceptance process in the user space area.
The suggestion from Leon is that within the maintainer team Doug would
deal primarily with all the user facing changes (eg libibverbs) and
other team members would deal with the internal things like provider
updates.
No one is suggesting to transfer libibverbs away from Doug's stewardship.
This means working with all the other vendors, and I know Leon has
been working to build those relationships/etc.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160907155849.GE2878-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-08 8:20 ` Sagi Grimberg
0 siblings, 0 replies; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-08 8:20 UTC (permalink / raw)
To: Jason Gunthorpe, Yishai Hadas
Cc: 'Doug Ledford',
Christoph Hellwig, Leon Romanovsky, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
>>> I think that Yishai and Doug maintaining libibverbs as a team would be
>>> great. Having said that, we'll need to understand if they are fine with
>>> it.
>>
>> Yes, I'm fine with taking responsibility and maintain libibverbs.
>> I believe that it will reduce burden from Doug and escalate the
>> development/acceptance process in the user space area.
>
> The suggestion from Leon is that within the maintainer team Doug would
> deal primarily with all the user facing changes (eg libibverbs) and
> other team members would deal with the internal things like provider
> updates.
>
> No one is suggesting to transfer libibverbs away from Doug's stewardship.
I wasn't suggesting taking anything from Doug either. Personally I
think that maintainer teams make sense also for a single
repository/subsystem, it has several successful examples around the
kernel.
Given that the patch traffic for libibverbs should be significantly
larger than the individual device drivers, maybe it makes sense
to share the load here (especially given that Doug has the RDMA kernel
tree which have seen increasingly growing activity).
Having said that, Doug as the current libibverbs maintainer should
decide if he wants any help. Either way we can probably see how things
roll when the process is applied...
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
` (17 preceding siblings ...)
2016-09-06 13:59 ` Hal Rosenstock
@ 2016-09-13 16:28 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB07FB7A-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
18 siblings, 1 reply; 174+ messages in thread
From: Hefty, Sean @ 2016-09-13 16:28 UTC (permalink / raw)
To: Jason Gunthorpe, Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Marciniszyn, Mike, Moni Shoua,
Steve Wise, Nikolova, Tatyana E, Vladimir Sokolovsky,
Yishai Hadas
> Jason Gunthorpe (15):
> Fix bogus executable file permissions
> umad: Include umad.h in the canonical way
> rdmacm: Control symbol export from librspreload
> ibcm: Actually use the version script when linking
> Include pthreads in the provider libraries
> Be explicit about _GNU_SOURCE
> hfi/ipath: Use the name of the provider for the .driver file
> Unified CMake build system
> Support obsolete cmake from 2013
> Remove the auto* based build systems
> Remove the ChangeLog files
> Combine COPYING files
> Consolidate the .gitignore files
> Move providers into providers/
> Add a MAINTAINERS file
I haven't read through this thread completely yet, but are you wanting patches applied to the current upstream trees before the merge, or are you good merging them into your local trees only?
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB07FB7A-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-13 16:51 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB07FBE1-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-13 18:06 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Hefty, Sean @ 2016-09-13 16:51 UTC (permalink / raw)
To: Hefty, Sean, Jason Gunthorpe, Doug Ledford,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
Cc: Devesh Sharma, Hal Rosenstock, Marciniszyn, Mike, Moni Shoua,
Steve Wise, Nikolova, Tatyana E, Vladimir Sokolovsky,
Yishai Hadas
> I haven't read through this thread completely yet, but are you wanting
> patches applied to the current upstream trees before the merge, or are
> you good merging them into your local trees only?
What is the intended scope for what goes into this repo? So far, what's there is very verbs focused. Is your intent to pull in non-verbs related interfaces (e.g. psm/psm2) as well? I see iwpm. What about ibacm, opensm, or the distributed SA work?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB07FBE1-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-13 18:03 ` Jason Gunthorpe
[not found] ` <20160913180342.GA6933-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-13 18:03 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
On Tue, Sep 13, 2016 at 04:51:41PM +0000, Hefty, Sean wrote:
> > I haven't read through this thread completely yet, but are you wanting
> > patches applied to the current upstream trees before the merge, or are
> > you good merging them into your local trees only?
>
> What is the intended scope for what goes into this repo? So far,
> what's there is very verbs focused. Is your intent to pull in
> non-verbs related interfaces (e.g. psm/psm2) as well? I see iwpm.
> What about ibacm, opensm, or the distributed SA work?
The intent is to cover the user space component of the kernel.
So, if code is including uapi/rdma/* then it is a good candidate for
this tree.
libacm, I am unclear on. Is it the recommended userspace component for
the netlink socket that Kaike? Is it coupled to librdmacm? If yes it
should probably come too.
psm/psm2, I have no knowledge about this, it seems to meet the
qualification, but I haven't seen it follow a community model? I
don't have an impression that Intel would view that favorably..
opensm is not qualified since it rides on the other libraries.
Not sure what distributed SA encompasses..
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB07FB7A-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-13 16:51 ` Hefty, Sean
@ 2016-09-13 18:06 ` Jason Gunthorpe
1 sibling, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-13 18:06 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
On Tue, Sep 13, 2016 at 04:28:42PM +0000, Hefty, Sean wrote:
> I haven't read through this thread completely yet, but are you
> wanting patches applied to the current upstream trees before the
> merge, or are you good merging them into your local trees only?
Hi Sean,
For this question you can probably jump directly to this thread.
http://www.spinics.net/lists/linux-rdma/msg40014.html
If you send me Reviewed-by's/Acks, or otherwise then I will carry it,
if you wish to grab them (as Steve and Sean did) then please do.
Within the github the commits up to 'Unified CMake build system' are
intended to be bug fixes to the current scheme of various kinds.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160913180342.GA6933-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-13 22:13 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08075C-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-16 16:56 ` Hal Rosenstock
1 sibling, 1 reply; 174+ messages in thread
From: Hefty, Sean @ 2016-09-13 22:13 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
> The intent is to cover the user space component of the kernel.
>
> So, if code is including uapi/rdma/* then it is a good candidate for
> this tree.
Based on discussions so far, I would limit the scope to the 'common' or 'shared' or non-vendor-specific areas of the uAPI.
> libacm, I am unclear on. Is it the recommended userspace component for
> the netlink socket that Kaike? Is it coupled to librdmacm? If yes it
> should probably come too.
Yes, this is the userspace daemon for the SA netlink socket. And to be clear, it's ibacm, as it's a daemon not a library. The librdmacm looks for and uses ibacm when present.
> psm/psm2, I have no knowledge about this, it seems to meet the
> qualification, but I haven't seen it follow a community model? I
> don't have an impression that Intel would view that favorably..
I couldn't say for certain, but my guess is that the psm team would like to maintain this separately. AFAIK, it has no dependency on verbs or the verbs uapi.
> opensm is not qualified since it rides on the other libraries.
>
> Not sure what distributed SA encompasses..
I'm not sure either at this point. It used to ride completely on the other libraries.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08075C-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-13 22:25 ` Jason Gunthorpe
[not found] ` <20160913222539.GB29095-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-13 22:25 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
On Tue, Sep 13, 2016 at 10:13:10PM +0000, Hefty, Sean wrote:
> > The intent is to cover the user space component of the kernel.
> >
> > So, if code is including uapi/rdma/* then it is a good candidate for
> > this tree.
>
> Based on discussions so far, I would limit the scope to the 'common'
> or 'shared' or non-vendor-specific areas of the uAPI.
Seems reasonable and on point..
> > libacm, I am unclear on. Is it the recommended userspace component for
> > the netlink socket that Kaike? Is it coupled to librdmacm? If yes it
> > should probably come too.
>
> Yes, this is the userspace daemon for the SA netlink socket. And to
> be clear, it's ibacm, as it's a daemon not a library. The librdmacm
> looks for and uses ibacm when present.
Yes/No to include it?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160913222539.GB29095-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-13 23:00 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB080798-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Hefty, Sean @ 2016-09-13 23:00 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
> > > libacm, I am unclear on. Is it the recommended userspace component
> for
> > > the netlink socket that Kaike? Is it coupled to librdmacm? If yes
> it
> > > should probably come too.
> >
> > Yes, this is the userspace daemon for the SA netlink socket. And to
> > be clear, it's ibacm, as it's a daemon not a library. The librdmacm
> > looks for and uses ibacm when present.
>
> Yes/No to include it?
I could go either way on this, but I'm leaning to no.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160905174636.GC14403-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-14 4:04 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-14 4:04 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Bart Van Assche, Steve Wise, 'Sagi Grimberg',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
On Mon, Sep 05, 2016 at 11:46:36AM -0600, Jason Gunthorpe wrote:
> On Mon, Sep 05, 2016 at 03:48:02PM +0300, Leon Romanovsky wrote:
>
> > > Folks can decide how much of this stuff should go on into the main
> > > repository later on..
> >
> > I completely missed that tooling branch. It looks like it misses the
> > Debian image.
>
> Only 'make' works for Debian. There is no .deb packaging yet.
I have just pushed sample Debian packaging, please let me know what
you think.
The DEB stuff is much closer to production ready than the RPM example,
and illistrates my proposed package split:
ibverbs-providers_11-1_amd64.deb
ibverbs-utils_11-1_amd64.deb
iwpmd_11-1_amd64.deb
libibcm-dev_1.0.11-1_amd64.deb
libibcm1-dbg_1.0.11-1_amd64.deb
libibcm1_1.0.11-1_amd64.deb
libibumad-dev_3.1.11-1_amd64.deb
libibumad3-dbg_3.1.11-1_amd64.deb
libibumad3_3.1.11-1_amd64.deb
libibverbs-dev_1.2.11-1_amd64.deb
libibverbs1-dbg_1.2.11-1_amd64.deb
libibverbs1_1.2.11-1_amd64.deb
librdmacm-dev_1.1.11-1_amd64.deb
librdmacm1-dbg_1.1.11-1_amd64.deb
librdmacm1_1.1.11-1_amd64.deb
rdmacm-utils_11-1_amd64.deb
srptools_11-1_amd64.deb
Debian will be able to gain 5 new providers, iwpmd and a spattering of
newer versions.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160906110729.GM21847-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-15 6:17 ` Christoph Hellwig
[not found] ` <20160915061753.GD4869-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Christoph Hellwig @ 2016-09-15 6:17 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Sagi Grimberg, Christoph Hellwig, Jason Gunthorpe, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Tue, Sep 06, 2016 at 02:07:29PM +0300, Leon Romanovsky wrote:
> On Tue, Sep 06, 2016 at 11:50:54AM +0300, Sagi Grimberg wrote:
> >
> > librdma maybe?
>
> It is not exactly library.
> Maybe rdma-bundle?
Or simple rdma-user?
Either way, plumbing is just a horrible out of place and confusing name
for software and we'll need to get rid of it.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915061753.GD4869-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2016-09-15 6:52 ` Leon Romanovsky
[not found] ` <20160915065242.GO26069-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-15 6:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Sagi Grimberg, Jason Gunthorpe, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
On Wed, Sep 14, 2016 at 11:17:53PM -0700, Christoph Hellwig wrote:
> On Tue, Sep 06, 2016 at 02:07:29PM +0300, Leon Romanovsky wrote:
> > On Tue, Sep 06, 2016 at 11:50:54AM +0300, Sagi Grimberg wrote:
> > >
> > > librdma maybe?
> >
> > It is not exactly library.
> > Maybe rdma-bundle?
>
> Or simple rdma-user?
>
> Either way, plumbing is just a horrible out of place and confusing name
> for software and we'll need to get rid of it.
We created github.com/linux-rdma/ organization. So the "rdma" can be
removed from the name.
What do you think about github.com/linux-rdma/userspace.git ?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915065242.GO26069-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-15 8:06 ` Christoph Hellwig
[not found] ` <20160915080600.GA31776-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Christoph Hellwig @ 2016-09-15 8:06 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Sagi Grimberg, Jason Gunthorpe, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Thu, Sep 15, 2016 at 09:52:42AM +0300, Leon Romanovsky wrote:
> On Wed, Sep 14, 2016 at 11:17:53PM -0700, Christoph Hellwig wrote:
> > On Tue, Sep 06, 2016 at 02:07:29PM +0300, Leon Romanovsky wrote:
> > > On Tue, Sep 06, 2016 at 11:50:54AM +0300, Sagi Grimberg wrote:
> > > >
> > > > librdma maybe?
> > >
> > > It is not exactly library.
> > > Maybe rdma-bundle?
> >
> > Or simple rdma-user?
> >
> > Either way, plumbing is just a horrible out of place and confusing name
> > for software and we'll need to get rid of it.
>
> We created github.com/linux-rdma/ organization. So the "rdma" can be
> removed from the name.
>
> What do you think about github.com/linux-rdma/userspace.git ?
That's very annoying if you actually clone it, or download tarballs.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915080600.GA31776-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2016-09-15 8:11 ` Leon Romanovsky
[not found] ` <20160915081149.GT26069-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-15 8:11 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Sagi Grimberg, Jason Gunthorpe, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
On Thu, Sep 15, 2016 at 01:06:00AM -0700, Christoph Hellwig wrote:
> On Thu, Sep 15, 2016 at 09:52:42AM +0300, Leon Romanovsky wrote:
> > On Wed, Sep 14, 2016 at 11:17:53PM -0700, Christoph Hellwig wrote:
> > > On Tue, Sep 06, 2016 at 02:07:29PM +0300, Leon Romanovsky wrote:
> > > > On Tue, Sep 06, 2016 at 11:50:54AM +0300, Sagi Grimberg wrote:
> > > > >
> > > > > librdma maybe?
> > > >
> > > > It is not exactly library.
> > > > Maybe rdma-bundle?
> > >
> > > Or simple rdma-user?
> > >
> > > Either way, plumbing is just a horrible out of place and confusing name
> > > for software and we'll need to get rid of it.
> >
> > We created github.com/linux-rdma/ organization. So the "rdma" can be
> > removed from the name.
> >
> > What do you think about github.com/linux-rdma/userspace.git ?
>
> That's very annoying if you actually clone it, or download tarballs.
Maybe we will cut it a little bit to be github.com/linux-rdma/user.git ?
Any suggestions are welcomed, we didn't do anything irreversible.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915081149.GT26069-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-15 8:13 ` Christoph Hellwig
[not found] ` <20160915081327.GA7572-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Christoph Hellwig @ 2016-09-15 8:13 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Sagi Grimberg, Jason Gunthorpe, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Thu, Sep 15, 2016 at 11:11:49AM +0300, Leon Romanovsky wrote:
> > > We created github.com/linux-rdma/ organization. So the "rdma" can be
> > > removed from the name.
> > >
> > > What do you think about github.com/linux-rdma/userspace.git ?
> >
> > That's very annoying if you actually clone it, or download tarballs.
>
> Maybe we will cut it a little bit to be github.com/linux-rdma/user.git ?
> Any suggestions are welcomed, we didn't do anything irreversible.
The annoying thing is not the userspace part, that is perfectly fine
with me. The problem is the lack of rdma- prefix which actually makes
the name maningful.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915081327.GA7572-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
@ 2016-09-15 8:39 ` Leon Romanovsky
[not found] ` <20160915083945.GU26069-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-15 8:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Sagi Grimberg, Jason Gunthorpe, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]
On Thu, Sep 15, 2016 at 01:13:27AM -0700, Christoph Hellwig wrote:
> On Thu, Sep 15, 2016 at 11:11:49AM +0300, Leon Romanovsky wrote:
> > > > We created github.com/linux-rdma/ organization. So the "rdma" can be
> > > > removed from the name.
> > > >
> > > > What do you think about github.com/linux-rdma/userspace.git ?
> > >
> > > That's very annoying if you actually clone it, or download tarballs.
> >
> > Maybe we will cut it a little bit to be github.com/linux-rdma/user.git ?
> > Any suggestions are welcomed, we didn't do anything irreversible.
>
> The annoying thing is not the userspace part, that is perfectly fine
> with me. The problem is the lack of rdma- prefix which actually makes
> the name maningful.
Thanks for the explanation,
It looks like we have two different options to address your concern.
Easy option is to include "rdma" word in the name and enjoy built-in
UI to release packages [1].
And the more advanced option will be to create scripts to automate
releases [2] and append "rdma" to the name.
[1] https://github.com/blog/1547-release-your-software
[2] https://developer.github.com/v3/repos/releases/#create-a-release
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915083945.GU26069-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-15 16:04 ` Jason Gunthorpe
[not found] ` <20160915160427.GC18154-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-15 16:04 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Christoph Hellwig, Sagi Grimberg, Steve Wise,
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Thu, Sep 15, 2016 at 11:39:45AM +0300, Leon Romanovsky wrote:
> Easy option is to include "rdma" word in the name and enjoy built-in
> UI to release packages [1].
I think we should do this, I agree with Christoph, if you go through
the github gui and pick the clone path in 'Clone or Download' then the
resulting clone should be called rdma-user/
I would not attempt to rename the tar file away from the repo
name. That is just confusing.
I'm not bothered by the stuttering rdma in the url.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915160427.GC18154-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-15 16:09 ` Steve Wise
2016-09-15 16:37 ` Leon Romanovsky
` (2 more replies)
0 siblings, 3 replies; 174+ messages in thread
From: Steve Wise @ 2016-09-15 16:09 UTC (permalink / raw)
To: 'Jason Gunthorpe', 'Leon Romanovsky'
Cc: 'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
> On Thu, Sep 15, 2016 at 11:39:45AM +0300, Leon Romanovsky wrote:
>
> > Easy option is to include "rdma" word in the name and enjoy built-in
> > UI to release packages [1].
>
> I think we should do this, I agree with Christoph, if you go through
> the github gui and pick the clone path in 'Clone or Download' then the
> resulting clone should be called rdma-user/
>
Ditto. And I like rdma-user over rdma-userspace...
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-15 16:09 ` Steve Wise
@ 2016-09-15 16:37 ` Leon Romanovsky
[not found] ` <20160915163756.GB26069-2ukJVAZIZ/Y@public.gmane.org>
2016-09-16 15:17 ` Doug Ledford
2016-09-18 16:48 ` Sagi Grimberg
2 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-15 16:37 UTC (permalink / raw)
To: Steve Wise
Cc: 'Jason Gunthorpe', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Thu, Sep 15, 2016 at 11:09:04AM -0500, Steve Wise wrote:
> > On Thu, Sep 15, 2016 at 11:39:45AM +0300, Leon Romanovsky wrote:
> >
> > > Easy option is to include "rdma" word in the name and enjoy built-in
> > > UI to release packages [1].
> >
> > I think we should do this, I agree with Christoph, if you go through
> > the github gui and pick the clone path in 'Clone or Download' then the
> > resulting clone should be called rdma-user/
> >
>
> Ditto. And I like rdma-user over rdma-userspace...
Looks nice.
Do we want to create rdma-tools after this task will be completed? For example
with debug and performance tools in it.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915163756.GB26069-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-15 16:39 ` Steve Wise
2016-09-15 16:44 ` Leon Romanovsky
2016-09-15 16:49 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Steve Wise @ 2016-09-15 16:39 UTC (permalink / raw)
To: 'Leon Romanovsky'
Cc: 'Jason Gunthorpe', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
> On Thu, Sep 15, 2016 at 11:09:04AM -0500, Steve Wise wrote:
> > > On Thu, Sep 15, 2016 at 11:39:45AM +0300, Leon Romanovsky wrote:
> > >
> > > > Easy option is to include "rdma" word in the name and enjoy built-in
> > > > UI to release packages [1].
> > >
> > > I think we should do this, I agree with Christoph, if you go through
> > > the github gui and pick the clone path in 'Clone or Download' then the
> > > resulting clone should be called rdma-user/
> > >
> >
> > Ditto. And I like rdma-user over rdma-userspace...
>
> Looks nice.
>
> Do we want to create rdma-tools after this task will be completed? For example
> with debug and performance tools in it.
I think so.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-15 16:39 ` Steve Wise
@ 2016-09-15 16:44 ` Leon Romanovsky
[not found] ` <20160915164416.GC26069-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-15 16:44 UTC (permalink / raw)
To: Steve Wise
Cc: 'Jason Gunthorpe', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]
On Thu, Sep 15, 2016 at 11:39:05AM -0500, Steve Wise wrote:
> > On Thu, Sep 15, 2016 at 11:09:04AM -0500, Steve Wise wrote:
> > > > On Thu, Sep 15, 2016 at 11:39:45AM +0300, Leon Romanovsky wrote:
> > > >
> > > > > Easy option is to include "rdma" word in the name and enjoy built-in
> > > > > UI to release packages [1].
> > > >
> > > > I think we should do this, I agree with Christoph, if you go through
> > > > the github gui and pick the clone path in 'Clone or Download' then the
> > > > resulting clone should be called rdma-user/
> > > >
> > >
> > > Ditto. And I like rdma-user over rdma-userspace...
> >
> > Looks nice.
> >
> > Do we want to create rdma-tools after this task will be completed? For example
> > with debug and performance tools in it.
>
> I think so.
And what is exactly srptools? From the name, it looks like good
candidate for rdma-tools.git, but it is in rdma-user.git noa.
What about rdma-libs.git instead of rdma-user.git?
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915163756.GB26069-2ukJVAZIZ/Y@public.gmane.org>
2016-09-15 16:39 ` Steve Wise
@ 2016-09-15 16:49 ` Jason Gunthorpe
[not found] ` <20160915164931.GC26111-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-15 16:49 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Steve Wise, 'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Thu, Sep 15, 2016 at 07:37:56PM +0300, Leon Romanovsky wrote:
> Do we want to create rdma-tools after this task will be completed? For example
> with debug and performance tools in it.
Prolification of repositories is exactly what this is intended to
prevent :(
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915164416.GC26069-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-15 16:49 ` Woodruff, Robert J
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE1641A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-15 19:04 ` Bart Van Assche
1 sibling, 1 reply; 174+ messages in thread
From: Woodruff, Robert J @ 2016-09-15 16:49 UTC (permalink / raw)
To: Leon Romanovsky, Steve Wise
Cc: 'Jason Gunthorpe', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong
Leon wrote,
>What about rdma-libs.git instead of rdma-user.git?
Or perhaps rdma-user-core.git since it will not include all userspace packages (e.g., perftests, opensm, etc.) and srptools contains a deamon and is not just a library.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915164931.GC26111-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-15 18:53 ` Leon Romanovsky
2016-09-15 19:09 ` Steve Wise
1 sibling, 0 replies; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-15 18:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, 'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
On Thu, Sep 15, 2016 at 10:49:32AM -0600, Jason Gunthorpe wrote:
> On Thu, Sep 15, 2016 at 07:37:56PM +0300, Leon Romanovsky wrote:
>
> > Do we want to create rdma-tools after this task will be completed? For example
> > with debug and performance tools in it.
>
> Prolification of repositories is exactly what this is intended to
> prevent :(
Anyway, we didn't plan to take tools to rdma-plumbing. Where do you
think we need put them? Tools repository looks like a good fit (in the
future).
>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE1641A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-15 18:55 ` Leon Romanovsky
0 siblings, 0 replies; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-15 18:55 UTC (permalink / raw)
To: Woodruff, Robert J
Cc: Steve Wise, 'Jason Gunthorpe',
'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
On Thu, Sep 15, 2016 at 04:49:36PM +0000, Woodruff, Robert J wrote:
> Leon wrote,
>
> >What about rdma-libs.git instead of rdma-user.git?
>
> Or perhaps rdma-user-core.git since it will not include all userspace packages (e.g., perftests, opensm, etc.) and srptools contains a deamon and is not just a library.
Is srptool library or is it tool?
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915164416.GC26069-2ukJVAZIZ/Y@public.gmane.org>
2016-09-15 16:49 ` Woodruff, Robert J
@ 2016-09-15 19:04 ` Bart Van Assche
[not found] ` <98fb59c6-2a6d-b36a-d582-e3b24a8d7024-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Bart Van Assche @ 2016-09-15 19:04 UTC (permalink / raw)
To: Leon Romanovsky, Steve Wise
Cc: 'Jason Gunthorpe', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On 09/15/2016 06:44 PM, Leon Romanovsky wrote:
> And what is exactly srptools? From the name, it looks like good
> candidate for rdma-tools.git, but it is in rdma-user.git noa.
Does this mean that you don't know how SRP login works? An SRP initiator
logs in to an SRP target if a login string is written into the
add_target sysfs attribute. Although it is possible to look up the
proper login string on the target system and to issue the login
manually, most SRP users run srp_daemon on the initiator system.
srp_daemon is a daemon that runs on SRP initiator systems, that
discovers SRP target systems and that logs in to these target systems if
allowed by /etc/srp_daemon.conf. I expect that all SRP users will
install the rdma-user package and that not all of them will need the
rdma-tools package. So for SRP users it will be convenient to include
srptools in the rdma-user package.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915164931.GC26111-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-15 18:53 ` Leon Romanovsky
@ 2016-09-15 19:09 ` Steve Wise
2016-09-15 19:26 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Steve Wise @ 2016-09-15 19:09 UTC (permalink / raw)
To: 'Jason Gunthorpe', 'Leon Romanovsky'
Cc: 'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
>
> On Thu, Sep 15, 2016 at 07:37:56PM +0300, Leon Romanovsky wrote:
>
> > Do we want to create rdma-tools after this task will be completed? For
example
> > with debug and performance tools in it.
>
> Prolification of repositories is exactly what this is intended to
> prevent :(
>
The goal would be to move all the tools/cmds/etc into one repo. How is that
prolification?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <98fb59c6-2a6d-b36a-d582-e3b24a8d7024-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
@ 2016-09-15 19:17 ` Leon Romanovsky
0 siblings, 0 replies; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-15 19:17 UTC (permalink / raw)
To: Bart Van Assche
Cc: Steve Wise, 'Jason Gunthorpe',
'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
On Thu, Sep 15, 2016 at 09:04:36PM +0200, Bart Van Assche wrote:
> On 09/15/2016 06:44 PM, Leon Romanovsky wrote:
> >And what is exactly srptools? From the name, it looks like good
> >candidate for rdma-tools.git, but it is in rdma-user.git noa.
>
> Does this mean that you don't know how SRP login works?
Yes, I had no idea about it.
> An SRP initiator
> logs in to an SRP target if a login string is written into the add_target
> sysfs attribute. Although it is possible to look up the proper login string
> on the target system and to issue the login manually, most SRP users run
> srp_daemon on the initiator system. srp_daemon is a daemon that runs on SRP
> initiator systems, that discovers SRP target systems and that logs in to
> these target systems if allowed by /etc/srp_daemon.conf. I expect that all
> SRP users will install the rdma-user package and that not all of them will
> need the rdma-tools package. So for SRP users it will be convenient to
> include srptools in the rdma-user package.
OK,
It makes sense to leave it in rdma-user.
Thanks for the explanation.
>
> Bart.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-15 19:09 ` Steve Wise
@ 2016-09-15 19:26 ` Jason Gunthorpe
[not found] ` <20160915192628.GB437-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-15 19:26 UTC (permalink / raw)
To: Steve Wise
Cc: 'Leon Romanovsky', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Thu, Sep 15, 2016 at 02:09:09PM -0500, Steve Wise wrote:
> > > Do we want to create rdma-tools after this task will be completed? For
> example
> > > with debug and performance tools in it.
> >
> > Prolification of repositories is exactly what this is intended to
> > prevent :(
>
> The goal would be to move all the tools/cmds/etc into one repo. How is that
> prolification?
I guess I should wait and see what could end up in there before
commenting...
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915192628.GB437-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-15 19:36 ` Steve Wise
2016-09-16 7:06 ` Weiny, Ira
2016-09-16 9:09 ` 'Christoph Hellwig'
1 sibling, 1 reply; 174+ messages in thread
From: Steve Wise @ 2016-09-15 19:36 UTC (permalink / raw)
To: 'Jason Gunthorpe'
Cc: 'Leon Romanovsky', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
> > > > Do we want to create rdma-tools after this task will be completed? For
> > example
> > > > with debug and performance tools in it.
> > >
> > > Prolification of repositories is exactly what this is intended to
> > > prevent :(
> >
> > The goal would be to move all the tools/cmds/etc into one repo. How is that
> > prolification?
>
> I guess I should wait and see what could end up in there before
> commenting...
>
I think we should shelf this discussion until we get our current project done...
But... :)
A quick gander at the OFED packages produces this list of possible candidates:
dapl (perhaps dapl should be in rdma-plumbing?)
fabtests
ibacm
ibpd
ibsim
ibutils
infiniband-diags
infinipath-psm
mstflint
opensm
perftest
qlvnictools
qperf
rds-tools
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-15 19:36 ` Steve Wise
@ 2016-09-16 7:06 ` Weiny, Ira
[not found] ` <2807E5FD2F6FDA4886F6618EAC48510E24EE4644-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Weiny, Ira @ 2016-09-16 7:06 UTC (permalink / raw)
To: Steve Wise, 'Jason Gunthorpe'
Cc: 'Leon Romanovsky', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', Marciniszyn, Mike, 'Moni Shoua',
Hefty, Sean, Nikolova, Tatyana E, 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org
>
> > > > > Do we want to create rdma-tools after this task will be
> > > > > completed? For
> > > example
> > > > > with debug and performance tools in it.
> > > >
> > > > Prolification of repositories is exactly what this is intended to
> > > > prevent :(
> > >
> > > The goal would be to move all the tools/cmds/etc into one repo. How
> > > is that prolification?
> >
> > I guess I should wait and see what could end up in there before
> > commenting...
> >
>
> I think we should shelf this discussion until we get our current project done...
>
> But... :)
>
> A quick gander at the OFED packages produces this list of possible
> candidates:
>
> dapl (perhaps dapl should be in rdma-plumbing?) fabtests ibacm ibpd ibsim
> ibutils infiniband-diags infinipath-psm mstflint opensm perftest qlvnictools
> qperf rds-tools
I strongly suggest against adding anything that is not a library and even then I like what Jason has said previously. "This is a library targeted for kernel APIs." So, for example, libibmad was not included. In fact architecturally I think ibmad should go away somehow. The main user is infiniband-diags but there are some other users of it so I have not been able to deprecate it.
I guess my opinion is I don't want to see this repo become "OFED" in a different form. There are valid reasons to have separate packages. It is really the support libraries which have been a pain.
Ira
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the
> body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160915192628.GB437-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-15 19:36 ` Steve Wise
@ 2016-09-16 9:09 ` 'Christoph Hellwig'
1 sibling, 0 replies; 174+ messages in thread
From: 'Christoph Hellwig' @ 2016-09-16 9:09 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, 'Leon Romanovsky',
'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
On Thu, Sep 15, 2016 at 01:26:28PM -0600, Jason Gunthorpe wrote:
> On Thu, Sep 15, 2016 at 02:09:09PM -0500, Steve Wise wrote:
> > > > Do we want to create rdma-tools after this task will be completed? For
> > example
> > > > with debug and performance tools in it.
> > >
> > > Prolification of repositories is exactly what this is intended to
> > > prevent :(
> >
> > The goal would be to move all the tools/cmds/etc into one repo. How is that
> > prolification?
>
> I guess I should wait and see what could end up in there before
> commenting...
To avoid too much bikeshedding I'd say start with the minimal version
of rdma-user.git first: basically the various libraries and core daemons,
as that's the major painpoint.
We can then decide what with the tools in a second step.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <2807E5FD2F6FDA4886F6618EAC48510E24EE4644-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-16 13:51 ` Steve Wise
2016-09-16 14:53 ` Leon Romanovsky
0 siblings, 1 reply; 174+ messages in thread
From: Steve Wise @ 2016-09-16 13:51 UTC (permalink / raw)
To: 'Weiny, Ira', 'Jason Gunthorpe'
Cc: 'Leon Romanovsky', 'Christoph Hellwig',
'Sagi Grimberg', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Marciniszyn, Mike',
'Moni Shoua', 'Hefty, Sean',
'Nikolova, Tatyana E', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
> >
> > > > > > Do we want to create rdma-tools after this task will be
> > > > > > completed? For
> > > > example
> > > > > > with debug and performance tools in it.
> > > > >
> > > > > Prolification of repositories is exactly what this is intended to
> > > > > prevent :(
> > > >
> > > > The goal would be to move all the tools/cmds/etc into one repo. How
> > > > is that prolification?
> > >
> > > I guess I should wait and see what could end up in there before
> > > commenting...
> > >
> >
> > I think we should shelf this discussion until we get our current project
done...
> >
> > But... :)
> >
> > A quick gander at the OFED packages produces this list of possible
> > candidates:
> >
> > dapl (perhaps dapl should be in rdma-plumbing?) fabtests ibacm ibpd ibsim
> > ibutils infiniband-diags infinipath-psm mstflint opensm perftest qlvnictools
> > qperf rds-tools
>
> I strongly suggest against adding anything that is not a library and even then
I like
> what Jason has said previously. "This is a library targeted for kernel APIs."
So, for
> example, libibmad was not included. In fact architecturally I think ibmad
should go
> away somehow. The main user is infiniband-diags but there are some other
users
> of it so I have not been able to deprecate it.
>
> I guess my opinion is I don't want to see this repo become "OFED" in a
different
> form. There are valid reasons to have separate packages. It is really the
support
> libraries which have been a pain.
This discussion where I've listed possible inclusions is for a rdma-tools
uber-repo, not the current plumbing repo (aka rdma-user).
However, I'm beginning to think there really is no need for an rdma-tools repo.
one benefit for having an rdma-user is to make it easy to do API changes and
global changes to all provider libs. For the rdma-tools and other packages that
use RDMA, that will probably never be needed.
Ok, this time I'm really done discussing an rdma-tools for now. :)
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-16 13:51 ` Steve Wise
@ 2016-09-16 14:53 ` Leon Romanovsky
0 siblings, 0 replies; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-16 14:53 UTC (permalink / raw)
To: Steve Wise
Cc: 'Weiny, Ira', 'Jason Gunthorpe',
'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas', 'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Marciniszyn, Mike',
'Moni Shoua', 'Hefty, Sean',
'Nikolova, Tatyana E', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]
On Fri, Sep 16, 2016 at 08:51:22AM -0500, Steve Wise wrote:
> > >
> > > > > > > Do we want to create rdma-tools after this task will be
> > > > > > > completed? For
> > > > > example
> > > > > > > with debug and performance tools in it.
> > > > > >
> > > > > > Prolification of repositories is exactly what this is intended to
> > > > > > prevent :(
> > > > >
> > > > > The goal would be to move all the tools/cmds/etc into one repo. How
> > > > > is that prolification?
> > > >
> > > > I guess I should wait and see what could end up in there before
> > > > commenting...
> > > >
> > >
> > > I think we should shelf this discussion until we get our current project
> done...
> > >
> > > But... :)
> > >
> > > A quick gander at the OFED packages produces this list of possible
> > > candidates:
> > >
> > > dapl (perhaps dapl should be in rdma-plumbing?) fabtests ibacm ibpd ibsim
> > > ibutils infiniband-diags infinipath-psm mstflint opensm perftest qlvnictools
> > > qperf rds-tools
> >
> > I strongly suggest against adding anything that is not a library and even then
> I like
> > what Jason has said previously. "This is a library targeted for kernel APIs."
> So, for
> > example, libibmad was not included. In fact architecturally I think ibmad
> should go
> > away somehow. The main user is infiniband-diags but there are some other
> users
> > of it so I have not been able to deprecate it.
> >
> > I guess my opinion is I don't want to see this repo become "OFED" in a
> different
> > form. There are valid reasons to have separate packages. It is really the
> support
> > libraries which have been a pain.
>
> This discussion where I've listed possible inclusions is for a rdma-tools
> uber-repo, not the current plumbing repo (aka rdma-user).
>
> However, I'm beginning to think there really is no need for an rdma-tools repo.
> one benefit for having an rdma-user is to make it easy to do API changes and
> global changes to all provider libs. For the rdma-tools and other packages that
> use RDMA, that will probably never be needed.
>
> Ok, this time I'm really done discussing an rdma-tools for now. :)
I talked about rdma-tools.git only and failed to understand why people started to add tools to rdma-user.git,
which is better to be called rdma-iibs.git.
Let's stop this discussion till better times.
>
> Steve.
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB080798-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-16 15:12 ` Doug Ledford
[not found] ` <edc4c963-847a-e973-f1f1-ab9b78ad9d19-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-09-16 15:12 UTC (permalink / raw)
To: Hefty, Sean, Jason Gunthorpe
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Hal Rosenstock,
Marciniszyn, Mike, Moni Shoua, Steve Wise, Nikolova, Tatyana E,
Vladimir Sokolovsky, Yishai Hadas
[-- Attachment #1.1: Type: text/plain, Size: 931 bytes --]
On 9/13/2016 7:00 PM, Hefty, Sean wrote:
>>>> libacm, I am unclear on. Is it the recommended userspace component
>> for
>>>> the netlink socket that Kaike? Is it coupled to librdmacm? If yes
>> it
>>>> should probably come too.
>>>
>>> Yes, this is the userspace daemon for the SA netlink socket. And to
>>> be clear, it's ibacm, as it's a daemon not a library. The librdmacm
>>> looks for and uses ibacm when present.
>>
>> Yes/No to include it?
>
> I could go either way on this, but I'm leaning to no.
>
I would. Mainly because it is tied to both the kernel uAPI (via
netlink) and to librdmacm (such that librdmacm changes how it builds
when ibacm is present, so if we don't include it, then ibacm becomes a
requirement of the larger package if you want librdmacm to support the
ibacm cache service).
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-15 16:09 ` Steve Wise
2016-09-15 16:37 ` Leon Romanovsky
@ 2016-09-16 15:17 ` Doug Ledford
2016-09-18 16:48 ` Sagi Grimberg
2 siblings, 0 replies; 174+ messages in thread
From: Doug Ledford @ 2016-09-16 15:17 UTC (permalink / raw)
To: Steve Wise, 'Jason Gunthorpe', 'Leon Romanovsky'
Cc: 'Christoph Hellwig', 'Sagi Grimberg',
'Yishai Hadas',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1.1: Type: text/plain, Size: 860 bytes --]
On 9/15/2016 12:09 PM, Steve Wise wrote:
>> On Thu, Sep 15, 2016 at 11:39:45AM +0300, Leon Romanovsky wrote:
>>
>>> Easy option is to include "rdma" word in the name and enjoy built-in
>>> UI to release packages [1].
>>
>> I think we should do this, I agree with Christoph, if you go through
>> the github gui and pick the clone path in 'Clone or Download' then the
>> resulting clone should be called rdma-user/
>>
>
> Ditto. And I like rdma-user over rdma-userspace...
rdma-user is decent, although I think I have a slight preference for
rdma-core just because part of what's in there is not really related to
user space operation, part of it is related to kernel RDMA feature
management (any init scripts, srptools, things like that).
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <edc4c963-847a-e973-f1f1-ab9b78ad9d19-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-09-16 16:16 ` Jason Gunthorpe
[not found] ` <20160916161626.GB2833-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-16 16:16 UTC (permalink / raw)
To: Doug Ledford
Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
On Fri, Sep 16, 2016 at 11:12:17AM -0400, Doug Ledford wrote:
> I would. Mainly because it is tied to both the kernel uAPI (via
> netlink)and to librdmacm
With what little I know about ibacm I'm inclined to agree. It seems
like a utility for librdmacm, and is consuming a kernel interface.
Reconsider Sean?
> (such that librdmacm changes how it builds when ibacm is present, so
> if we don't include it, then ibacm becomes a requirement of the
> larger package if you want librdmacm to support the ibacm cache
> service).
I double checked and I couldn't find anything like
this. librdmacm/src/amc.c builds unconditionally and contains no
ifdefs, configure does not key on anything to do with acm.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160916161626.GB2833-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-16 16:24 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08C5F3-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-16 16:34 ` Doug Ledford
1 sibling, 1 reply; 174+ messages in thread
From: Hefty, Sean @ 2016-09-16 16:24 UTC (permalink / raw)
To: Jason Gunthorpe, Doug Ledford
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma, Hal Rosenstock,
Marciniszyn, Mike, Moni Shoua, Steve Wise, Nikolova, Tatyana E,
Vladimir Sokolovsky, Yishai Hadas
> > I would. Mainly because it is tied to both the kernel uAPI (via
> > netlink)and to librdmacm
>
> With what little I know about ibacm I'm inclined to agree. It seems
> like a utility for librdmacm, and is consuming a kernel interface.
>
> Reconsider Sean?
Yes - Doug made a good point. The librdmacm and ibacm share a protocol, which I think I ended up copying into both packages.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160916161626.GB2833-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-16 16:24 ` Hefty, Sean
@ 2016-09-16 16:34 ` Doug Ledford
[not found] ` <de8022d4-debb-2366-48c9-fdd8e391eb4b-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Doug Ledford @ 2016-09-16 16:34 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
[-- Attachment #1.1: Type: text/plain, Size: 1061 bytes --]
On 9/16/2016 12:16 PM, Jason Gunthorpe wrote:
> On Fri, Sep 16, 2016 at 11:12:17AM -0400, Doug Ledford wrote:
>
>> I would. Mainly because it is tied to both the kernel uAPI (via
>> netlink)and to librdmacm
>
> With what little I know about ibacm I'm inclined to agree. It seems
> like a utility for librdmacm, and is consuming a kernel interface.
>
> Reconsider Sean?
>
>> (such that librdmacm changes how it builds when ibacm is present, so
>> if we don't include it, then ibacm becomes a requirement of the
>> larger package if you want librdmacm to support the ibacm cache
>> service).
>
> I double checked and I couldn't find anything like
> this. librdmacm/src/amc.c builds unconditionally and contains no
> ifdefs, configure does not key on anything to do with acm.
Sorry, must have changed. It used to do so (configure used to test for
presence of ibacm header file and change compile settings accordingly as
I recall).
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <de8022d4-debb-2366-48c9-fdd8e391eb4b-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-09-16 16:46 ` Hal Rosenstock
0 siblings, 0 replies; 174+ messages in thread
From: Hal Rosenstock @ 2016-09-16 16:46 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Marciniszyn, Mike, Moni Shoua, Steve Wise, Nikolova, Tatyana E,
Vladimir Sokolovsky, Yishai Hadas
On 9/16/2016 12:34 PM, Doug Ledford wrote:
> On 9/16/2016 12:16 PM, Jason Gunthorpe wrote:
>> On Fri, Sep 16, 2016 at 11:12:17AM -0400, Doug Ledford wrote:
>>
>>> I would. Mainly because it is tied to both the kernel uAPI (via
>>> netlink)and to librdmacm
>>
>> With what little I know about ibacm I'm inclined to agree. It seems
>> like a utility for librdmacm, and is consuming a kernel interface.
>>
>> Reconsider Sean?
>>
>>> (such that librdmacm changes how it builds when ibacm is present, so
>>> if we don't include it, then ibacm becomes a requirement of the
>>> larger package if you want librdmacm to support the ibacm cache
>>> service).
>>
>> I double checked and I couldn't find anything like
>> this. librdmacm/src/amc.c builds unconditionally and contains no
>> ifdefs, configure does not key on anything to do with acm.
>
> Sorry, must have changed. It used to do so (configure used to test for
> presence of ibacm header file and change compile settings accordingly as
> I recall).
Yes, you recall correctly; this change is in librdmacm 1.0.18 and beyond:
commit c8be3cfde6902e490fadd6a51206c1bcba3e3aa2
Author: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date: Mon Jun 10 10:57:56 2013 -0700
init: Remove USE_IB_ACM configuration option
When the librdmacm is configured, it sets the USE_IB_ACM option
if infininband/acm.h is found. We can remove this option with
very little overhead, which would allow a user to install
ACM after installing the librdmacm, and the librdmacm would be
able to make use of ACM.
Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08C5F3-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-16 16:55 ` Jason Gunthorpe
[not found] ` <20160916165500.GA15159-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-19 18:55 ` Jason Gunthorpe
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-16 16:55 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
On Fri, Sep 16, 2016 at 04:24:37PM +0000, Hefty, Sean wrote:
> > > I would. Mainly because it is tied to both the kernel uAPI (via
> > > netlink)and to librdmacm
> >
> > With what little I know about ibacm I'm inclined to agree. It seems
> > like a utility for librdmacm, and is consuming a kernel interface.
> >
> > Reconsider Sean?
>
> Yes - Doug made a good point. The librdmacm and ibacm share a
> protocol, which I think I ended up copying into both packages.
Okay, what is the cannonical git url? Sean, you are still the maintainer?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160913180342.GA6933-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-13 22:13 ` Hefty, Sean
@ 2016-09-16 16:56 ` Hal Rosenstock
[not found] ` <9aaeb3e2-9283-9850-0dfa-d1ea150e7408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Hal Rosenstock @ 2016-09-16 16:56 UTC (permalink / raw)
To: Jason Gunthorpe, Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Marciniszyn, Mike, Moni Shoua, Steve Wise, Nikolova, Tatyana E,
Vladimir Sokolovsky, Yishai Hadas
On 9/13/2016 2:03 PM, Jason Gunthorpe wrote:
> opensm is not qualified since it rides on the other libraries.
I'm not sure whether opensm should be in or out. However, I don't
understand the not qualified part. It does seem to be similar to both
srptools and ibacm which are all daemons and live on top of libibverbs
and libibumad (ibacm has addition netlink socket support).
What are the metrics for inclusion ?
What other libraries are you referring to ? OpenSM lives on top of
libibumad and two internal libraries (complib and a "vendor" library).
-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <9aaeb3e2-9283-9850-0dfa-d1ea150e7408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
@ 2016-09-16 17:04 ` Jason Gunthorpe
[not found] ` <20160916170403.GB15159-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-16 17:04 UTC (permalink / raw)
To: Hal Rosenstock
Cc: Hefty, Sean, Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Devesh Sharma, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
On Fri, Sep 16, 2016 at 12:56:55PM -0400, Hal Rosenstock wrote:
> On 9/13/2016 2:03 PM, Jason Gunthorpe wrote:
> > opensm is not qualified since it rides on the other libraries.
>
> I'm not sure whether opensm should be in or out. However, I don't
> understand the not qualified part. It does seem to be similar to both
> srptools and ibacm which are all daemons and live on top of libibverbs
> and libibumad (ibacm has addition netlink socket support).
srp_daemon and iwpmd are both bits of code that reasonably could have
lived in the kernel but have been punted to user space to keep the
kernel simpler. For instance srp_daemon's job is to collect service
record from the SM and tell the kernel about it.
ibacm can reasonably considered a linked subcomponent of librdmacm.
> What are the metrics for inclusion ?
Unclear :)
> What other libraries are you referring to ? OpenSM lives on top of
> libibumad and two internal libraries (complib and a "vendor" library).
Those are the libraries.
opensm is not bound to kernel, does not use the kernel 'uabi' headers,
is not a part of the kernel that was delgated to userspace, and is not
required/related to any of the subcomponents already in the tree.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160916165500.GA15159-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-16 17:13 ` Hefty, Sean
0 siblings, 0 replies; 174+ messages in thread
From: Hefty, Sean @ 2016-09-16 17:13 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
> Okay, what is the cannonical git url? Sean, you are still the
> maintainer?
https://github.com/ofiwg/librdmacm
https://github.com/ofiwg/ibacm
I am still the maintainer for both.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160916170403.GB15159-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-16 18:08 ` Doug Ledford
0 siblings, 0 replies; 174+ messages in thread
From: Doug Ledford @ 2016-09-16 18:08 UTC (permalink / raw)
To: Jason Gunthorpe, Hal Rosenstock
Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Marciniszyn, Mike, Moni Shoua, Steve Wise, Nikolova, Tatyana E,
Vladimir Sokolovsky, Yishai Hadas
[-- Attachment #1.1: Type: text/plain, Size: 1477 bytes --]
On 9/16/2016 1:04 PM, Jason Gunthorpe wrote:
> On Fri, Sep 16, 2016 at 12:56:55PM -0400, Hal Rosenstock wrote:
>> On 9/13/2016 2:03 PM, Jason Gunthorpe wrote:
>>> opensm is not qualified since it rides on the other libraries.
>>
>> I'm not sure whether opensm should be in or out. However, I don't
>> understand the not qualified part. It does seem to be similar to both
>> srptools and ibacm which are all daemons and live on top of libibverbs
>> and libibumad (ibacm has addition netlink socket support).
>
> srp_daemon and iwpmd are both bits of code that reasonably could have
> lived in the kernel but have been punted to user space to keep the
> kernel simpler. For instance srp_daemon's job is to collect service
> record from the SM and tell the kernel about it.
>
> ibacm can reasonably considered a linked subcomponent of librdmacm.
>
>> What are the metrics for inclusion ?
>
> Unclear :)
>
>> What other libraries are you referring to ? OpenSM lives on top of
>> libibumad and two internal libraries (complib and a "vendor" library).
>
> Those are the libraries.
>
> opensm is not bound to kernel, does not use the kernel 'uabi' headers,
> is not a part of the kernel that was delgated to userspace, and is not
> required/related to any of the subcomponents already in the tree.
Not to mention it's also a complex beast ;-)
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
2016-09-15 16:09 ` Steve Wise
2016-09-15 16:37 ` Leon Romanovsky
2016-09-16 15:17 ` Doug Ledford
@ 2016-09-18 16:48 ` Sagi Grimberg
[not found] ` <33226ea3-bd5c-c40c-8080-def9d98980f9-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2 siblings, 1 reply; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-18 16:48 UTC (permalink / raw)
To: Steve Wise, 'Jason Gunthorpe', 'Leon Romanovsky'
Cc: 'Christoph Hellwig', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
>>> Easy option is to include "rdma" word in the name and enjoy built-in
>>> UI to release packages [1].
>>
>> I think we should do this, I agree with Christoph, if you go through
>> the github gui and pick the clone path in 'Clone or Download' then the
>> resulting clone should be called rdma-user/
>>
>
> Ditto. And I like rdma-user over rdma-userspace...
+1 for rdma-user
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <33226ea3-bd5c-c40c-8080-def9d98980f9-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
@ 2016-09-18 16:53 ` Leon Romanovsky
[not found] ` <20160918165354.GK2923-2ukJVAZIZ/Y@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Leon Romanovsky @ 2016-09-18 16:53 UTC (permalink / raw)
To: Sagi Grimberg
Cc: Steve Wise, 'Jason Gunthorpe',
'Christoph Hellwig', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
On Sun, Sep 18, 2016 at 07:48:23PM +0300, Sagi Grimberg wrote:
>
> >>>Easy option is to include "rdma" word in the name and enjoy built-in
> >>>UI to release packages [1].
> >>
> >>I think we should do this, I agree with Christoph, if you go through
> >>the github gui and pick the clone path in 'Clone or Download' then the
> >>resulting clone should be called rdma-user/
> >>
> >
> >Ditto. And I like rdma-user over rdma-userspace...
>
> +1 for rdma-user
We went after Doug's suggestion - rdma-core.git
Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160918165354.GK2923-2ukJVAZIZ/Y@public.gmane.org>
@ 2016-09-18 17:04 ` Sagi Grimberg
0 siblings, 0 replies; 174+ messages in thread
From: Sagi Grimberg @ 2016-09-18 17:04 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Steve Wise, 'Jason Gunthorpe',
'Christoph Hellwig', 'Yishai Hadas',
'Doug Ledford',
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas', 'Majd Dibbiny',
liranl-VPRAkNaXOzVWk0Htik3J/w, talal-VPRAkNaXOzVWk0Htik3J/w,
yarong-VPRAkNaXOzVWk0Htik3J/w
> We went after Doug's suggestion - rdma-core.git
Fine with me too.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08C5F3-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-16 16:55 ` Jason Gunthorpe
@ 2016-09-19 18:55 ` Jason Gunthorpe
[not found] ` <20160919185502.GA12436-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
1 sibling, 1 reply; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-19 18:55 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
On Fri, Sep 16, 2016 at 04:24:37PM +0000, Hefty, Sean wrote:
> > > I would. Mainly because it is tied to both the kernel uAPI (via
> > > netlink)and to librdmacm
> >
> > With what little I know about ibacm I'm inclined to agree. It seems
> > like a utility for librdmacm, and is consuming a kernel interface.
> >
> > Reconsider Sean?
>
> Yes - Doug made a good point. The librdmacm and ibacm share a
> protocol, which I think I ended up copying into both packages.
I would delete the windows support in that package if we take it into
rdma-core.
Is that OK?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* RE: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <20160919185502.GA12436-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2016-09-19 18:58 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08D2CD-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 174+ messages in thread
From: Hefty, Sean @ 2016-09-19 18:58 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
> I would delete the windows support in that package if we take it into
> rdma-core.
>
> Is that OK?
That's fine with me. I haven't tested on windows in a long time. I'm not sure how usable it is, as no one is maintaining the libibverbs and libibumad windows ports.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08D2CD-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
@ 2016-09-19 22:54 ` Jason Gunthorpe
0 siblings, 0 replies; 174+ messages in thread
From: Jason Gunthorpe @ 2016-09-19 22:54 UTC (permalink / raw)
To: Hefty, Sean
Cc: Doug Ledford, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Devesh Sharma,
Hal Rosenstock, Marciniszyn, Mike, Moni Shoua, Steve Wise,
Nikolova, Tatyana E, Vladimir Sokolovsky, Yishai Hadas
On Mon, Sep 19, 2016 at 06:58:52PM +0000, Hefty, Sean wrote:
> > I would delete the windows support in that package if we take it into
> > rdma-core.
> >
> > Is that OK?
>
> That's fine with me. I haven't tested on windows in a long time.
> I'm not sure how usable it is, as no one is maintaining the
> libibverbs and libibumad windows ports.
Okay, it is up now. I haven't done all the steps, but call it a draft.
https://github.com/jgunthorpe/rdma-plumbing/tree/master/ibacm
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
* Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo
[not found] ` <fcfcff11-fe5c-6cf5-3575-52da4b9241ed-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
@ 2016-09-21 17:21 ` ira.weiny
0 siblings, 0 replies; 174+ messages in thread
From: ira.weiny @ 2016-09-21 17:21 UTC (permalink / raw)
To: Doug Ledford
Cc: Leon Romanovsky, Jason Gunthorpe, Jarod Wilson, Steve Wise,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, 'Devesh Sharma',
'Hal Rosenstock', 'Mike Marciniszyn',
'Moni Shoua', 'Sean Hefty',
'Tatyana Nikolova', 'Vladimir Sokolovsky',
'Yishai Hadas'
>
> Unfortunataely, what you speak of is not really realistic, both for the
> reasons I've cited and a whole litany of other reasons I didn't mention.
>
> But I don't think Jason jumped in to work on this because of the goal of
> making Red Hat's life easier in packaging up the separate code. He did
> it for upstream related reasons:
>
> 1) Put all of the providers and libibverbs in one place so that they can
> be kept in sync. This allows us to do the exact same thing we do with
> the kernel in user space. Namely, if someone makes an incompatible
> change in the libibverbs core, we can require that they fix up all
> providers in the same patch series. This works rather well for the
> kernel, and it would be good to bring that policy to user space too.
>
> 2) Put all of the kernel interacting libraries in one place. This makes
> it easier to perform the write->ioctl conversion we've been discussing
> as there would be only one larger package that needs to be updated for
> any given kernel ioctl update.
>
> 3) Bring librdmacm and libibverbs together so that the occasional
> incompatible update between the two is not an issue any more.
>
> 4) Create an easier to build/install package for developers to use.
>
> Those are the issues we should be discussing the relative merits of in
> order to determine whether this work should be adopted.
>
I see one more benefit here. This should give us an opportunity to consolidate
and clarify the interface to the _users_ of these libraries. For example it
has always bothered me is there are about 3 places that a PathRecord struct was
defined. To be clear I think PathRecords should be hidden from the user but in
general keeping a clean interface to the user between librdmacm, libibverbs,
and to a lesser extent (or maybe not at all) libibumad would be very nice for
the end user.
Ira
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 174+ messages in thread
end of thread, other threads:[~2016-09-21 17:21 UTC | newest]
Thread overview: 174+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-22 18:13 [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo Jason Gunthorpe
[not found] ` <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-22 18:13 ` [RFCv2 01/15] Fix bogus executable file permissions Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 02/15] umad: Include umad.h in the canonical way Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 03/15] rdmacm: Control symbol export from librspreload Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 04/15] ibcm: Actually use the version script when linking Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 05/15] Include pthreads in the provider libraries Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 06/15] Be explicit about _GNU_SOURCE Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 07/15] hfi/ipath: Use the name of the provider for the .driver file Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 08/15] Unified CMake build system Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 09/15] Support obsolete cmake from 2013 Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 10/15] Remove the auto* based build systems Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 11/15] Remove the ChangeLog files Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 12/15] Combine COPYING files Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 13/15] Consolidate the .gitignore files Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 14/15] Move providers into providers/ Jason Gunthorpe
2016-08-22 18:13 ` [RFCv2 15/15] Add a MAINTAINERS file Jason Gunthorpe
2016-08-22 20:06 ` [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo Steve Wise
2016-08-22 20:12 ` Steve Wise
2016-08-22 21:43 ` Jason Gunthorpe
[not found] ` <20160822214352.GB11695-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-23 18:54 ` Jason Gunthorpe
[not found] ` <20160823185441.GA1233-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-25 14:20 ` Doug Ledford
[not found] ` <cabbd0a7-0918-a8dd-d1e5-0b079f0c4604-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-25 14:22 ` Doug Ledford
[not found] ` <f98718ea-72b5-e157-5f16-14ca51a85c53-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-25 16:47 ` Jason Gunthorpe
[not found] ` <20160825164753.GB20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-27 2:22 ` Doug Ledford
2016-08-25 17:39 ` Jason Gunthorpe
[not found] ` <20160825173916.GC20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-25 19:52 ` Jarod Wilson
[not found] ` <20160825195246.GI1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-25 20:13 ` Jason Gunthorpe
[not found] ` <20160825201306.GA5421-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-25 20:32 ` Steve Wise
2016-08-26 15:42 ` Jarod Wilson
[not found] ` <20160826154206.GK1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-26 22:27 ` Jason Gunthorpe
[not found] ` <20160826222725.GA8553-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-27 3:00 ` Doug Ledford
[not found] ` <5421f173-384d-faef-0eab-518db6dad0e5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-27 3:50 ` Jason Gunthorpe
2016-08-30 1:27 ` Jarod Wilson
[not found] ` <20160830012738.GH6803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-01 18:12 ` Doug Ledford
2016-09-06 19:26 ` Jason Gunthorpe
2016-08-27 3:17 ` Doug Ledford
[not found] ` <8ef70f6c-e26d-191d-9a9a-2e0bf47fb227-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-08-27 5:21 ` Jason Gunthorpe
2016-08-28 13:28 ` Leon Romanovsky
[not found] ` <20160828132804.GN594-2ukJVAZIZ/Y@public.gmane.org>
2016-08-28 18:36 ` Jason Gunthorpe
[not found] ` <20160828183627.GC12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-29 6:29 ` Leon Romanovsky
[not found] ` <20160829062918.GR594-2ukJVAZIZ/Y@public.gmane.org>
2016-08-29 16:00 ` Jason Gunthorpe
[not found] ` <20160829160009.GA23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-30 5:43 ` Leon Romanovsky
[not found] ` <20160830054352.GI594-2ukJVAZIZ/Y@public.gmane.org>
2016-08-30 16:47 ` Jason Gunthorpe
2016-09-01 18:51 ` Doug Ledford
[not found] ` <fcfcff11-fe5c-6cf5-3575-52da4b9241ed-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-21 17:21 ` ira.weiny
2016-08-27 3:34 ` Doug Ledford
2016-08-28 16:14 ` Yishai Hadas
[not found] ` <c84de2a5-6526-c0a6-6535-519add3fbabb-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-08-28 18:27 ` Jason Gunthorpe
[not found] ` <20160828182715.GA12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-29 12:07 ` Yishai Hadas
[not found] ` <765b7e2d-51e0-98aa-60d1-26be35eb7a3d-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-08-29 16:34 ` Jason Gunthorpe
[not found] ` <20160829163453.GC23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-29 20:03 ` Yishai Hadas
[not found] ` <aaf8d6ba-6dc2-51d9-b014-dcc10114079f-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-08-29 20:37 ` Jason Gunthorpe
[not found] ` <20160829203711.GC3201-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-30 8:13 ` Yishai Hadas
[not found] ` <60e502b0-0933-588e-8afe-afead230b2a1-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-08-30 16:10 ` Jason Gunthorpe
2016-08-29 14:39 ` Steve Wise
2016-08-29 16:19 ` Jason Gunthorpe
[not found] ` <20160829161902.GB23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-30 6:08 ` Leon Romanovsky
[not found] ` <20160830060842.GJ594-2ukJVAZIZ/Y@public.gmane.org>
2016-08-30 7:17 ` Christoph Hellwig
[not found] ` <20160830071716.GA3098-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-08-30 7:35 ` Leon Romanovsky
[not found] ` <20160830073521.GM594-2ukJVAZIZ/Y@public.gmane.org>
2016-08-30 16:30 ` Jason Gunthorpe
[not found] ` <20160830163033.GC26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-30 19:02 ` Leon Romanovsky
2016-09-04 8:18 ` Sagi Grimberg
[not found] ` <4b791de5-0d6e-fd94-8a31-2fe833ca72db-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-04 8:35 ` Leon Romanovsky
[not found] ` <20160904083517.GN21847-2ukJVAZIZ/Y@public.gmane.org>
2016-09-04 10:36 ` Sagi Grimberg
[not found] ` <a220db98-ebbf-5df4-e011-8804442796b8-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-04 21:40 ` Doug Ledford
[not found] ` <280b8620-0996-a9bc-dc93-bf5d710dd6de-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-05 1:51 ` Jason Gunthorpe
2016-09-05 5:29 ` Leon Romanovsky
2016-09-06 7:01 ` Christoph Hellwig
[not found] ` <20160906070102.GA23248-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-06 8:50 ` Sagi Grimberg
[not found] ` <6d47ca96-25eb-8358-879d-fc646ddda9cb-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-06 11:07 ` Leon Romanovsky
[not found] ` <20160906110729.GM21847-2ukJVAZIZ/Y@public.gmane.org>
2016-09-15 6:17 ` Christoph Hellwig
[not found] ` <20160915061753.GD4869-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-15 6:52 ` Leon Romanovsky
[not found] ` <20160915065242.GO26069-2ukJVAZIZ/Y@public.gmane.org>
2016-09-15 8:06 ` Christoph Hellwig
[not found] ` <20160915080600.GA31776-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-15 8:11 ` Leon Romanovsky
[not found] ` <20160915081149.GT26069-2ukJVAZIZ/Y@public.gmane.org>
2016-09-15 8:13 ` Christoph Hellwig
[not found] ` <20160915081327.GA7572-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-15 8:39 ` Leon Romanovsky
[not found] ` <20160915083945.GU26069-2ukJVAZIZ/Y@public.gmane.org>
2016-09-15 16:04 ` Jason Gunthorpe
[not found] ` <20160915160427.GC18154-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-15 16:09 ` Steve Wise
2016-09-15 16:37 ` Leon Romanovsky
[not found] ` <20160915163756.GB26069-2ukJVAZIZ/Y@public.gmane.org>
2016-09-15 16:39 ` Steve Wise
2016-09-15 16:44 ` Leon Romanovsky
[not found] ` <20160915164416.GC26069-2ukJVAZIZ/Y@public.gmane.org>
2016-09-15 16:49 ` Woodruff, Robert J
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE1641A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-15 18:55 ` Leon Romanovsky
2016-09-15 19:04 ` Bart Van Assche
[not found] ` <98fb59c6-2a6d-b36a-d582-e3b24a8d7024-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-09-15 19:17 ` Leon Romanovsky
2016-09-15 16:49 ` Jason Gunthorpe
[not found] ` <20160915164931.GC26111-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-15 18:53 ` Leon Romanovsky
2016-09-15 19:09 ` Steve Wise
2016-09-15 19:26 ` Jason Gunthorpe
[not found] ` <20160915192628.GB437-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-15 19:36 ` Steve Wise
2016-09-16 7:06 ` Weiny, Ira
[not found] ` <2807E5FD2F6FDA4886F6618EAC48510E24EE4644-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-16 13:51 ` Steve Wise
2016-09-16 14:53 ` Leon Romanovsky
2016-09-16 9:09 ` 'Christoph Hellwig'
2016-09-16 15:17 ` Doug Ledford
2016-09-18 16:48 ` Sagi Grimberg
[not found] ` <33226ea3-bd5c-c40c-8080-def9d98980f9-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-18 16:53 ` Leon Romanovsky
[not found] ` <20160918165354.GK2923-2ukJVAZIZ/Y@public.gmane.org>
2016-09-18 17:04 ` Sagi Grimberg
2016-09-06 18:34 ` Jason Gunthorpe
[not found] ` <20160906183405.GA27914-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-07 6:56 ` Leon Romanovsky
2016-09-07 8:21 ` Sagi Grimberg
[not found] ` <cd964412-11f3-d1ca-ef76-830a24cb8e68-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-07 13:14 ` Yishai Hadas
[not found] ` <924d7775-0d24-e1ca-b0ee-226df053089a-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-09-07 15:58 ` Jason Gunthorpe
[not found] ` <20160907155849.GE2878-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-08 8:20 ` Sagi Grimberg
2016-09-06 19:38 ` Jason Gunthorpe
2016-08-30 16:53 ` Jason Gunthorpe
[not found] ` <20160830165352.GE26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-08-30 18:38 ` Leon Romanovsky
2016-08-31 17:40 ` Woodruff, Robert J
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE04100-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-08-31 20:03 ` Jason Gunthorpe
[not found] ` <20160831200336.GA4134-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 8:26 ` Christoph Hellwig
[not found] ` <20160901082643.GA19799-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2016-09-01 11:03 ` Leon Romanovsky
[not found] ` <20160901110352.GI3694-2ukJVAZIZ/Y@public.gmane.org>
2016-09-01 12:39 ` Christoph Lameter
[not found] ` <alpine.DEB.2.20.1609010736370.31007-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>
2016-09-01 13:07 ` Leon Romanovsky
[not found] ` <20160901130705.GC21847-2ukJVAZIZ/Y@public.gmane.org>
2016-09-01 14:11 ` Christoph Lameter
2016-09-01 18:14 ` Jason Gunthorpe
[not found] ` <20160901181421.GE20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 19:46 ` Doug Ledford
2016-09-01 17:52 ` Jason Gunthorpe
[not found] ` <20160901175230.GD20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 19:14 ` Woodruff, Robert J
[not found] ` <9C6B67F36DCAFC479B1CF6A967258A8C7DE04AA2-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-01 19:32 ` Jason Gunthorpe
2016-09-01 14:21 ` Woodruff, Robert J
2016-09-01 15:29 ` ira.weiny
[not found] ` <20160901152920.GA23742-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
2016-09-01 17:09 ` Jason Gunthorpe
[not found] ` <20160901170955.GA19982-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 19:38 ` Doug Ledford
[not found] ` <a27267c8-3d5c-cdfe-ed2a-d57cb106a3bf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-01 20:17 ` Jason Gunthorpe
[not found] ` <20160901201727.GG20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-04 21:38 ` Doug Ledford
[not found] ` <9efe8c8f-40e2-b016-9a1e-4770298b9068-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-05 2:34 ` Jason Gunthorpe
2016-09-02 2:04 ` ira.weiny
[not found] ` <20160902020411.GD23742-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>
2016-09-02 17:18 ` Jason Gunthorpe
2016-09-01 15:24 ` Sagi Grimberg
[not found] ` <4f0876ce-f3c9-83e3-d0ef-0c5656ce9462-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2016-09-01 15:29 ` Steve Wise
2016-09-01 15:56 ` Bart Van Assche
[not found] ` <53eb35b4-0320-acd9-9969-73f5817c8144-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-09-01 17:23 ` Jason Gunthorpe
[not found] ` <20160901172355.GA20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-01 18:36 ` Steve Wise
2016-09-02 23:32 ` Jason Gunthorpe
[not found] ` <20160902233231.GA26309-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-03 0:10 ` Bart Van Assche
[not found] ` <ef8214f8-d44d-2289-d1ed-a0998e9e05c0-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-09-03 5:12 ` Jason Gunthorpe
2016-09-03 14:08 ` Bart Van Assche
[not found] ` <BLUPR02MB16836859F638150FF6330A0A81E40-Y8PPn9RqzNfZ9ihocuPUdanrV9Ap65cLvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2016-09-05 4:10 ` Jason Gunthorpe
[not found] ` <20160903051222.GA2098-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-04 5:54 ` Leon Romanovsky
[not found] ` <20160904055441.GI21847-2ukJVAZIZ/Y@public.gmane.org>
2016-09-04 23:55 ` Jason Gunthorpe
[not found] ` <20160904235555.GA21542-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-05 12:48 ` Leon Romanovsky
[not found] ` <20160905124802.GX21847-2ukJVAZIZ/Y@public.gmane.org>
2016-09-05 17:46 ` Jason Gunthorpe
[not found] ` <20160905174636.GC14403-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-14 4:04 ` Jason Gunthorpe
2016-09-04 21:47 ` Doug Ledford
2016-09-01 19:49 ` Doug Ledford
[not found] ` <3a266ff7-006f-3d27-9e07-9e2e3ba2d1f9-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-01 19:52 ` Steve Wise
2016-09-01 20:21 ` Jason Gunthorpe
[not found] ` <20160901202110.GH20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-04 21:45 ` Doug Ledford
2016-09-04 7:55 ` Sagi Grimberg
2016-09-04 15:07 ` Bart Van Assche
2016-09-06 13:59 ` Hal Rosenstock
[not found] ` <bb889a58-331c-8ba8-920d-e3a79072dce4-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-09-06 16:37 ` Jason Gunthorpe
[not found] ` <20160906163708.GA3862-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-06 17:05 ` Hal Rosenstock
[not found] ` <a815efb1-424f-10a6-468e-d94f420a73be-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-09-06 18:15 ` Jason Gunthorpe
2016-09-13 16:28 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB07FB7A-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-13 16:51 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB07FBE1-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-13 18:03 ` Jason Gunthorpe
[not found] ` <20160913180342.GA6933-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-13 22:13 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08075C-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-13 22:25 ` Jason Gunthorpe
[not found] ` <20160913222539.GB29095-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-13 23:00 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB080798-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-16 15:12 ` Doug Ledford
[not found] ` <edc4c963-847a-e973-f1f1-ab9b78ad9d19-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-16 16:16 ` Jason Gunthorpe
[not found] ` <20160916161626.GB2833-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-16 16:24 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08C5F3-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-16 16:55 ` Jason Gunthorpe
[not found] ` <20160916165500.GA15159-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-16 17:13 ` Hefty, Sean
2016-09-19 18:55 ` Jason Gunthorpe
[not found] ` <20160919185502.GA12436-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-19 18:58 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373AB08D2CD-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2016-09-19 22:54 ` Jason Gunthorpe
2016-09-16 16:34 ` Doug Ledford
[not found] ` <de8022d4-debb-2366-48c9-fdd8e391eb4b-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-09-16 16:46 ` Hal Rosenstock
2016-09-16 16:56 ` Hal Rosenstock
[not found] ` <9aaeb3e2-9283-9850-0dfa-d1ea150e7408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
2016-09-16 17:04 ` Jason Gunthorpe
[not found] ` <20160916170403.GB15159-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-09-16 18:08 ` Doug Ledford
2016-09-13 18:06 ` Jason Gunthorpe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.