On Tue, Apr 19, 2016 at 08:44:50PM +0000, Hefty, Sean wrote: > > Right - and the RDMA uAPI has always had an integrated driver-bypass > > channel as part of the verb uAPI calls, extending that to allow for > > new-driver-specific calls seems very natural. > > I remain unconvinced that having the equivalent of: > > 1 open unrelated-interface > 2 ioctl open-file > 3 close unrelated-interface > > is desirable. I think you should explain what you see as the down side. So far the counter arguments seem terribly weak: - The file is called /dev/uverbs0 so everything in it must be 'verbs' and anything else new needs a new name (the name has no functional purpose, compatability requires some sacrifices) - Our current kapi requires a driver provide all the verbs before it can create uverbs0 (we could fix this) - The driver-specific ioctls have nothing to do with the subsystem and shouldn't be a part of it (then get the code out of drivers/infiniband) I've already outlined the tangible advantages from the whole system perspective on discoverability/security/deployment/etc. If you don't like the sub-fd then advocate for driver-specific ioctl on the main fd, I don't much care. <shrug> > If you want to push for a generic mechanism for mapping NIC > resources into user space, then separate that from the device > implementation. I don't understand this sentence, is it another shot at the fact the RDMA device specific cdev is called 'uverbs' ?? Seriously, every single new char dev that requires the same security context as uverbs (ie access from unprivledged users) is a *huge pain* to deploy out into the world, sysadmins need to be trained, distros need to be updated, orchestration stuff needs fixing, etc. It is simply not a sane path for our subsystem to require a multitude of these cdevs. If /dev/hfiX was to remain as root.root 0600 in the typical deployment, like most driver-specific cdevs then I'd be alot less concerned. But it isn't, and the garbage that was in there (like eeprom writing!?!) is totally *insane* for an unprivileged fd. 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
