Re: [RFC ABI V2 5/8] RDMA/core: Add new ioctl interface

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html