>> As for the 'one char device', I actually think it would be really >> simple. >> >> Add a new uverbs ioctl: >> >> int hfi1_fd = ioctl(uverbs_fd, RDMA_GET_DRIVER_OPS_FD, >> "psm2.intel.com"); >> >> ioctl(hfi1_fd, HFI1_IOCTL_ASSIGN_CTXT, ...); write(hfi1_fd, ...); >> >> At least that gives us far better options for discovery and versioning >> of this stuff than a driver-specific char device. >I think it would help the discussion if the advantages/disadvantages of this approach were described over just opening a driver specific file. Because trying >to form an application interface that's the union of hardware interfaces seems problematic. We _may_ be better thinking in terms if an Infiniband Core + >iWarp Core + PSM Core (with appropriate code re-use between them), than viewing the entire world as RDMA Core. I say may because I haven't thought >through the details. But from a high level, the IB core and PSM core appear to have basically no overlap. Seems to me that routing all PSM ioctls through the IB core makes about as much sense as sending all netlink packets through the SCSI mid-layer to get to a netdev driver. As Sean points out, there is basically no overlap between IB core and PSM capabilities, so there is no value added in passing PSM ioctls through the IB core. -- 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
