On Thu, Jul 21, 2016 at 02:11:56AM -0500, Christoph Lameter wrote: > On Wed, 20 Jul 2016, Jason Gunthorpe wrote: > > > > Well there is no need to do that with the standard way. The filehandle > > > identifies the driver. No need to modify strace and no need to > > > schlepp the device_id around. > > > > Nope, that isn't how strace works, strace never checks the filehandle. > > Ok why would strace check a filehandle in the first place? The descriptor > is the filehandle and you can simply find the operation that created that > file descriptor to find the device it refers to. strace is stateless and can attach to a running process, it can't watch for open() to figure things out. This is also why it doesn't inspect the filehandle... We don't *need* strace to work, but it should would be nice :| > > I mean in IB, we don't have the ability to securely strip a single > > port out of a device. This is why /dev/uverbs0 referes to both ports > > on a card. Adding that ability would damage API capabilities we have. > > We could easily do that following naming conventions for partitions or so. > Why would doing so damage the API capabilities? Seems that they are > sufficiently screwed up already. Cleaning that up could help quite a bit. The current API is problematic because we try to both be like netdev in that all devices are accessible (rdma_cm) and at the same with with individual per-device chardevs (uverbs0). The mismatch sucks and the two do not get along together as well at they should, which leads to even more goofyness in the design of things like rdma_cm :( So, if you want to move fully to the per-char-dev model then I think we'd give up the global netdev like behaviors, things like listen(0.0.0) and output route selection, and so forth. I doubt there is any support for that. If we go the other way to a full netdev-like module then we give up fine grained (currently mildly broken) file system permissions. > > There is no proposal to eliminate the multiplexors, I don't even know > > how that could work... > > I thought I just tried to outline how that could work. Consistently use > the device semantics already provided in the kernel and use the > functionality through ioctls, fnctls etc etc as already provided. You haven't explained how we can mesh the rdma_cm, netdev-like listen(0.0.0.0) type semantics, continue to implement multi-port APM functionality, share PDs across ports, etc, etc. These are all the actual things done today that break when we drop the multiplexors. This isn't a simple API that is 1:1 tied to a single physical object, it is a sprawling thing with lots of built-in cross-device semantics. :( 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
