* [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
[parent not found: <1471889618-1605-1-git-send-email-jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* [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 + buildlib/publish_headers.cmake | 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 diff --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
[parent not found: <20160822214352.GB11695-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160823185441.GA1233-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <cabbd0a7-0918-a8dd-d1e5-0b079f0c4604-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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
[parent not found: <f98718ea-72b5-e157-5f16-14ca51a85c53-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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
[parent not found: <20160825164753.GB20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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
[parent not found: <20160825173916.GC20612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160825195246.GI1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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
[parent not found: <20160825201306.GA5421-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160826154206.GK1916-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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
[parent not found: <20160826222725.GA8553-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <5421f173-384d-faef-0eab-518db6dad0e5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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] ` <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
[parent not found: <20160830012738.GH6803-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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] ` <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] ` <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
[parent not found: <8ef70f6c-e26d-191d-9a9a-2e0bf47fb227-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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
[parent not found: <20160828132804.GN594-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160828183627.GC12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160829062918.GR594-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160829160009.GA23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160830054352.GI594-2ukJVAZIZ/Y@public.gmane.org>]
* 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] ` <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
[parent not found: <fcfcff11-fe5c-6cf5-3575-52da4b9241ed-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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
* 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] ` <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
[parent not found: <c84de2a5-6526-c0a6-6535-519add3fbabb-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* 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
[parent not found: <20160828182715.GA12783-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <765b7e2d-51e0-98aa-60d1-26be35eb7a3d-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* 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
[parent not found: <20160829163453.GC23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <aaf8d6ba-6dc2-51d9-b014-dcc10114079f-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* 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
[parent not found: <20160829203711.GC3201-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <60e502b0-0933-588e-8afe-afead230b2a1-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* 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] ` <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 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
[parent not found: <20160829161902.GB23557-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160830060842.GJ594-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160830071716.GA3098-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* 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
[parent not found: <20160830073521.GM594-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160830163033.GC26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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
[parent not found: <4b791de5-0d6e-fd94-8a31-2fe833ca72db-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>]
* 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
[parent not found: <20160904083517.GN21847-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <a220db98-ebbf-5df4-e011-8804442796b8-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>]
* 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
[parent not found: <280b8620-0996-a9bc-dc93-bf5d710dd6de-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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] ` <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] ` <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
[parent not found: <20160906070102.GA23248-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* 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
[parent not found: <6d47ca96-25eb-8358-879d-fc646ddda9cb-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>]
* 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
[parent not found: <20160906110729.GM21847-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160915061753.GD4869-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* 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
[parent not found: <20160915065242.GO26069-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160915080600.GA31776-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* 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
[parent not found: <20160915081149.GT26069-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160915081327.GA7572-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* 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
[parent not found: <20160915083945.GU26069-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160915160427.GC18154-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160915163756.GB26069-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160915164416.GC26069-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <9C6B67F36DCAFC479B1CF6A967258A8C7DE1641A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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
[parent not found: <98fb59c6-2a6d-b36a-d582-e3b24a8d7024-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>]
* 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 [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
[parent not found: <20160915164931.GC26111-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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 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
[parent not found: <20160915192628.GB437-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <2807E5FD2F6FDA4886F6618EAC48510E24EE4644-8k97q/ur5Z2krb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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] ` <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 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 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
[parent not found: <33226ea3-bd5c-c40c-8080-def9d98980f9-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>]
* 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
[parent not found: <20160918165354.GK2923-2ukJVAZIZ/Y@public.gmane.org>]
* 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] ` <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
[parent not found: <20160906183405.GA27914-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <cd964412-11f3-d1ca-ef76-830a24cb8e68-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>]
* 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
[parent not found: <924d7775-0d24-e1ca-b0ee-226df053089a-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* 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
[parent not found: <20160907155849.GE2878-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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] ` <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
[parent not found: <20160830165352.GE26778-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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
[parent not found: <9C6B67F36DCAFC479B1CF6A967258A8C7DE04100-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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
[parent not found: <20160831200336.GA4134-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160901082643.GA19799-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]
* 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
[parent not found: <20160901110352.GI3694-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <alpine.DEB.2.20.1609010736370.31007-wcBtFHqTun5QOdAKl3ChDw@public.gmane.org>]
* 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
[parent not found: <20160901130705.GC21847-2ukJVAZIZ/Y@public.gmane.org>]
* 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] ` <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
[parent not found: <20160901181421.GE20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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
[parent not found: <20160901175230.GD20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <9C6B67F36DCAFC479B1CF6A967258A8C7DE04AA2-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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] ` <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] ` <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
[parent not found: <20160901152920.GA23742-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>]
* 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
[parent not found: <20160901170955.GA19982-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <a27267c8-3d5c-cdfe-ed2a-d57cb106a3bf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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
[parent not found: <20160901201727.GG20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <9efe8c8f-40e2-b016-9a1e-4770298b9068-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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] ` <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
[parent not found: <20160902020411.GD23742-W4f6Xiosr+yv7QzWx2u06xL4W9x8LtSr@public.gmane.org>]
* 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 [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
[parent not found: <4f0876ce-f3c9-83e3-d0ef-0c5656ce9462-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>]
* 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
[parent not found: <53eb35b4-0320-acd9-9969-73f5817c8144-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>]
* 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
[parent not found: <20160901172355.GA20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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 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
[parent not found: <20160902233231.GA26309-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <ef8214f8-d44d-2289-d1ed-a0998e9e05c0-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>]
* 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
[parent not found: <BLUPR02MB16836859F638150FF6330A0A81E40-Y8PPn9RqzNfZ9ihocuPUdanrV9Ap65cLvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>]
* 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
[parent not found: <20160903051222.GA2098-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160904055441.GI21847-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160904235555.GA21542-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <20160905124802.GX21847-2ukJVAZIZ/Y@public.gmane.org>]
* 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
[parent not found: <20160905174636.GC14403-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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] ` <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
[parent not found: <3a266ff7-006f-3d27-9e07-9e2e3ba2d1f9-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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 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
[parent not found: <20160901202110.GH20472-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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 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] ` <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
[parent not found: <bb889a58-331c-8ba8-920d-e3a79072dce4-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* 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
[parent not found: <20160906163708.GA3862-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <a815efb1-424f-10a6-468e-d94f420a73be-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* 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] ` <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
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB07FB7A-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB07FBE1-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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
[parent not found: <20160913180342.GA6933-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB08075C-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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
[parent not found: <20160913222539.GB29095-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB080798-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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
[parent not found: <edc4c963-847a-e973-f1f1-ab9b78ad9d19-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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
[parent not found: <20160916161626.GB2833-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB08C5F3-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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
[parent not found: <20160916165500.GA15159-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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] ` <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
[parent not found: <20160919185502.GA12436-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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
[parent not found: <1828884A29C6694DAF28B7E6B8A82373AB08D2CD-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>]
* 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] ` <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
[parent not found: <de8022d4-debb-2366-48c9-fdd8e391eb4b-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* 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] ` <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
[parent not found: <9aaeb3e2-9283-9850-0dfa-d1ea150e7408-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]
* 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
[parent not found: <20160916170403.GB15159-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]
* 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 [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
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.