RE: [RFC] rdma/uverbs: Sketch for an ioctl framework

Steve Wise
2016-05-25T22:47:29Z

>
> > > I want the core ioctl framework to do this:
> > >
> > > 1. Map user objects to/from the kernel to validate pointers.
> > > 2. Provide reference counting on such objects, in order to protect against
the
> user attempting to
> > destroy objects that are in use.
> > > 3. Provide protection that the state of an object is not driven in two
different
> directions.
> > > 4. Safely process the removal of the underlying driver or device.
> > > 5. Support driver specific operations to the kernel.
> > > 6. Report events from multiple sources to a single file descriptor.
> > > 7. Minimize the kernel footprint for allocated kernel objects.
> > > 8. Minimize the code path needed to process any ioctl, without greatly
affecting
> maintainability.
> > > 9. Copy ioctl input/output data to/from the kernel.
> >
> > I agree with all of this as a suitable goal for the common
> > dispatch/marshal framework.
> >
> > I like the idea of the generic uobject stuff in your patches.
> >
> > #6 seems 'not like the others' - seems like a reasonable concrete
> > thing to consider as we build the objects on the
> > framework. [understanding that compat operation is still required]
>
> I agree. Handling event reporting in general is slightly different from the
other
> objections. But it ties in with object close processing, so I think the
framework
> needs something here.
>
> #6 is based on examining the application APIs and driving requirements down.
I.e.
> poll a single fd to get all events: CQ notifications, async events, CM
disconnect
> events, etc. And while I'm thinking about it, expand events to support user
> specified. This would allow many apps to rid themselves of socketpairs which
> currently fill that role.
>

Applications I have written that block typically put the CQ, async, rdmacm fds
all into an poll/epoll group and block that way. But a common mechanism for
events might end up cleaner and simpler...