> > 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. The RDMA stack currently allows drivers to export their own interfaces directly to user space. 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. If the RDMA "community" defines the ultimate ioctl interface ever created, great. Every driver added after that interface has been defined and merged can be forced to use it. - Sean -- 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
