On Wed, Jul 20, 2016 at 07:57:09PM -0500, Christoph Lameter wrote: > > The device_id part of the extension allows each driver to have its own > > globally unique number space without requireing another ioctl block. > > 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. 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. > > No, strace doesn't know what an open FD is, it just inspects the ioctl > > # and content to do its decode. Requiring strace to decode differently > > depending on what was opened would be the deviation from what we do > > today. > > 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. .. 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. What we have today really doesn't make much sense. 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
