From: Leon Romanovsky <leonro@xxxxxxxxxxxx>
>From Matan:
This series contains improvements to RDMA ioctl() infrastructure.
Later patches will use this extensively.
The first patch moves to a new consistent naming. We link different
methods and handlers by using DECLARE_UVERBS_NAMED_METHOD and
UVERBS_HANDLER macros (similarly for objects). This makes it easier to
find how objects, methods and handlers
are linked together.
This patch also contains a major change towards sharing uapi headers
between user-space and kernel. The new files are named as follows:
[subsystem]_user_ioctl_[cmds/verbs].
[subsystem] = rdma, ib, provider drivers.
rdma contains standard ioctl() infrastructure definitions.
ib contains the verbs definitions.
Different provider drivers contain their own uapi structs
and definitions.
[cmds/verbs] = The goal here to share as much between applications and
kernel, thus avoid unnecessary copies. Therefore,
sometimes we need to export an attribute struct that will
be given straight from the user-space. In order to achieve
that, we split the definitions into to: _verbs.h include
structs and enums that should be used straight from the
application, while _cmds.h file includes the rest (mainly,
definitions that are only used by the communicating
library).
The second patch adds a driver_id to the uverbs_hdr. Since this uapi is
still experimental. We're enhancing it before turning it on by default.
This could be later use for having a smart strace (that decodes commands
successfully).
The third patch adds a compact representation of attribute
specifications. Since we plan to have a lot of attributes from different types,
we want to minimize our memory footprint. This makes sure that adding enum
attributes (will be added in a next series) doesn't affect our memory
footprint too much.
The fourth patch adds a way to safely extend attributes. The spec
language is enhanced to contain more than the sizeof(type). We state the
minimal acceptable size and the known kernel size. The parser checks
that it was given at least the minimal size and that all the unknown size
is zeroed. This is used by the new UVERBS_ATTR_SPEC_F_MIN_SZ_OR_ZERO flag which
replaces the old UVERBS_ATTR_SPEC_F_MIN_SZ one. Unbounded size is given
as minimum zero and USHRT_MAX known size.
The fifth patch exposes the uverbs standard parsing tree. Previously,
when the uverbs client registered, it registered the standard parsing
tree (if the driver hasn't registered one of its own). Up until now, no
driver had a custom parsing tree, but since we're going to add a driver
that uses both the standard parsing tree and adds some additions to it,
we want to expose the custom tree for being used in the provider drivers.
The sixth patch moves all related cq definitions into its own file. This
is done in order to prevent bogging up uverbs_std_types.c.
The seventh patch enhances the macro language for (common) cases where
the provider driver wants to enhance an existing method with some new
attributes. Instead of defining the whole hierarchy, the provider driver
could just use ADD_UVERBS_ATTRIBUTES and add these new attributes easily.
The eighth patch enables the ioctl() infrastructure by default. Only
verbs which exist both in the write() and ioctl() path are placed under
an experimental #ifdef.
Changes from V0:
- Each object has its own file.
- Add macros that helps the provider drivers to easily add
attributes to existing common methods.
- Fix a bug in extending inline PTR_IN attributes by size.
- Use the same DECLARE_UVERBS_NAMED_ macros both in the common and
provider drivers code.
Thanks
Matan Barak (8):
IB/uverbs: Move to new headers and make naming consistent
IB/uverbs: Extend uverbs_ioctl header with driver_id
IB/uverbs: Enable compact representation of uverbs_attr_spec
IB/uverbs: Safely extend existing attributes
IB/uverbs: Expose parsing tree of all common objects to providers
IB/uverbs: Move ioctl path of create_cq and destroy_cq to a new file
IB/uverbs: Add macros to simplify adding driver specific attributes
IB/uverbs: Enable ioctl() uAPI by default for new verbs
drivers/infiniband/Kconfig | 11 +-
drivers/infiniband/core/Makefile | 2 +-
drivers/infiniband/core/uverbs.h | 21 ++
drivers/infiniband/core/uverbs_cmd.c | 118 ++++----
drivers/infiniband/core/uverbs_ioctl.c | 22 +-
drivers/infiniband/core/uverbs_ioctl_merge.c | 2 +-
drivers/infiniband/core/uverbs_main.c | 4 -
drivers/infiniband/core/uverbs_std_types.c | 303 +++++----------------
drivers/infiniband/core/uverbs_std_types_cq.c | 210 ++++++++++++++
drivers/infiniband/hw/bnxt_re/main.c | 1 +
drivers/infiniband/hw/cxgb3/iwch_provider.c | 1 +
drivers/infiniband/hw/cxgb4/provider.c | 1 +
drivers/infiniband/hw/hfi1/verbs.c | 2 +-
drivers/infiniband/hw/hns/hns_roce_main.c | 1 +
drivers/infiniband/hw/i40iw/i40iw_verbs.c | 1 +
drivers/infiniband/hw/mlx4/main.c | 1 +
drivers/infiniband/hw/mlx5/main.c | 1 +
drivers/infiniband/hw/mthca/mthca_provider.c | 1 +
drivers/infiniband/hw/nes/nes_verbs.c | 1 +
drivers/infiniband/hw/ocrdma/ocrdma_main.c | 1 +
drivers/infiniband/hw/qedr/main.c | 1 +
drivers/infiniband/hw/qib/qib_verbs.c | 2 +-
drivers/infiniband/hw/usnic/usnic_ib_main.c | 1 +
drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 1 +
drivers/infiniband/sw/rdmavt/vt.c | 3 +-
drivers/infiniband/sw/rxe/rxe_verbs.c | 1 +
include/rdma/ib_verbs.h | 15 +-
include/rdma/rdma_vt.h | 2 +-
include/rdma/uverbs_ioctl.h | 104 +++++--
include/rdma/uverbs_named_ioctl.h | 90 ++++++
include/rdma/uverbs_std_types.h | 34 +--
...{ib_user_ioctl_verbs.h => ib_user_ioctl_cmds.h} | 43 ++-
include/uapi/rdma/ib_user_ioctl_verbs.h | 53 +---
include/uapi/rdma/rdma_user_ioctl.h | 38 +--
...b_user_ioctl_verbs.h => rdma_user_ioctl_cmds.h} | 89 +++---
35 files changed, 672 insertions(+), 510 deletions(-)
create mode 100644 drivers/infiniband/core/uverbs_std_types_cq.c
create mode 100644 include/rdma/uverbs_named_ioctl.h
copy include/uapi/rdma/{ib_user_ioctl_verbs.h => ib_user_ioctl_cmds.h} (72%)
copy include/uapi/rdma/{ib_user_ioctl_verbs.h => rdma_user_ioctl_cmds.h} (51%)
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
