On Wed, 20 Jul 2016, Jason Gunthorpe wrote: > > > > But you already have that uniqueness if the ioctl filehandle provides > > that. > > The argument is that ioctls should be self-describing and never rely > on the filehandle to uniq them. That is basically standard in the > kernel, and why we have Documentation/ioctl/ioctl-number.txt > describing how to uniquely assign ioctl numbers. Fully agree with that. But this statement does not relate to what we were talking about. So I guess I need to restate it one more time: device_id is useless if the driver is already determined by the device filehanle. > There is nothing special here, we are just creating a much larger > ioctl # space by using (ioctl #, operation, device_id) as the globally > unique key, following existing best-practice if self-identifying ioctls. > > > multi-device requirements in the network code require a new device that > > aggregates the other ones. The aggregation device is not world accessible. > > The same approach could be used for RDMA. > > Some do, some don't. The rdma_cm requirement is more like > listen(0.0.0.0) which does not require special net device aggregation. Well that concept is for a packetized protocol stack. In that kind of a system packets can be routed over multiple devices depending on the address. We do not have that in the IB stack. Routing of packets would require kernel code to run for each packet. Instead we have mostly point to point RDMA requests. So thos consideration is not for the IB stack. > > It is the basic Unix convention to have a descriptor/file handle refer to > > a device. There is nothing special required here from strace. > Sometimes yes, sometimes no. There are lots of examples both ways. > > /dev/pts/ptmx, /dev/mapper/control, /dev/btrfs-control, etc, etc are > all examples of multi-device control fds similar to the proposed > single char dev. Yes but those are not used for communications. They are used to control a subsystem and access to those requires special priviledges. We are talking about a device accessible witout special priviledges to do data communications. /dev/rdmaXXXX to control global behavior of the stack for all processes would be fine. But we are controlling the interaction of a process with a device. > .. and bear in mind that /dev/uverbs0 doesn't even really make that > much sense as it aggregates two physical ports. There is already no > way to split permissions up by port, which is a logical thing to want > for some dual-rail configurations. Right lets get rid of it. device specific files only. > What we have today really doesn't make much sense. Indeed lets adopt the standard filehandles for ioctls and other function calls as much as posssible. One may then be able to reuse other existing ioctls and other function calls for those filehandles (like fcntl which I mentioned earlier). -- 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
