On Fri, Apr 15, 2016 at 09:04:26PM +0000, Hefty, Sean wrote: > > > If we consider a completely non-verbs device, what unrelated code > > > and modules must be loaded for that device to export its interfaces > > > to user space? Force loading the infiniband stack for a non-IB > > > device seems like the wrong approach. > > > > I'm not even slightly concerned about that. This is HPC, if you care > > about a 100k kernel module you are doing something wrong. > > 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. 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. 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. > The RDMA stack currently allows drivers to export their own > interfaces directly to user space. Which way do you mean? > At this point, I see no reason why we should block a driver for > following what has been an acceptable practice for years. Dennis > fixed the write/writev issue, which would make the hfi1 driver the > only device in the RDMA tree with an acceptable interface. Acceptable practice changes, and I feel it's been made very clear that the subsystem is responsible for whatever insane uAPI people want to cram into a driver. So, now driver uapis have to be fully reviewed, and justified. cdev is clearly not the way forward. Plus, the 'kernel rule of threes', usnic and qib are two examples of an ugly pattern. hfi is the third. Third person gets to refactor the mess. Sorry. Jason -- 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
