On Fri, Apr 15, 2016 at 04:03:40PM -0600, Jason Gunthorpe wrote: > On Fri, Apr 15, 2016 at 09:04:26PM +0000, Hefty, Sean wrote: > > > > I wasn't referring to a software interface, but interface to the HW. > > A device like usNIC should not have to depend on ib_core and ib_mad > > because it wants to expose its interfaces up to user space. That > > makes no sense. I'm pretty sure that we're going to continue to > > disagree on this. > > That is a kapi issue. I'm confused, how is a device wanting to expose its interface to user space a kapi issue? > > The problem with usnic is that it is a totally unique un-generic thing > that tried to abuse an existing uapi to get into the kernel. > > qib/hfi's psm cdev interface is basically in the same boat. I really did not track the usnic additions but I don't see how we have _abused_ any uapi? Recognizing that PSM != Verbs, we have exported a new uAPI which directly access our PSM specific hardware. With the exception of the write/writev issue (which this series fixes); How is creating a char device abusing an existing uapi? > > The RDMA_DRIVER_OPS thing is one way to deal with expanding our > subsystem to cover a generic class of kernel-DMA-bypass devices - > especially those that don't have any sort of industry-standard or > common API. > > There is no reason a future kapi couldn't support null's on the verbs > driver ops and let a driver only use RDMA_DRIVER_OPS. usnic probably > would have been a lot better off like that - make it very clear it has > nothing to do with verbs, rdma, standards, etc. These statements conflict with your previous argument regarding the use of the /dev/infiniband/uverbsX devices... How can it be __clear__ that a device has "nothing to do with verbs, rdma, standards, etc.", when the device the user is opening is called /dev/infiniband/uverbsX ? To me opening /dev/hfi1_X is pretty clear that this is not an infiniband nor a verbs interface... I think you make a _lot_ of _good_ points regarding the use of a common cdev. I also recognize the pragmatism of using /dev/infiniband/uverbsX. However, I think we need to be honest with ourselves about what your proposal does. I am still not clear what would have happened had we not exported a verbs device _at_ _all_. In that case would creating a cdev even be a concern? Where and how would hfi1 fit into the kernel if we did not export a verbs interface at all? I truely don't know the answer to these questions. Ira -- 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
