Re: [PATCH 06/10] IB/hfi1: Add ioctl() interface for user commands

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

On Sun, May 22, 2016 at 10:03:52AM -0400, Dennis Dalessandro wrote:
> On Sun, May 22, 2016 at 03:01:29PM +0300, Leon Romanovsky wrote:
> >>>I think the overall consensus over participants in OFVWG call was to use
> >>>one IOCTL to enter into device specific handler which will do all
> >>>necessary parsing and not spamming common IOCTL interface.
> >>
> >>That was for the verbs working group and the verbs 2.0 uAPI. This is for
> >>psm.
> >
> >I'm glad that you are supporting my point.
> >It is vendor specific implementation for vendor specific driver and not
> >for whole IB core, so there is no need to pollute general IB ioctls.
> 
> It is making use of and applying a proper classification.  Is there a
> technical concern with this other than that's not how verbs may end up doing
> it?
> 
> I'm not completely opposed to the single ioctl, I just don't necessarily see
> that as better in this case but am willing to listen to a technical
> justification for why it's incorrect.

it will simplify internal and external development by removing the
tensions over ioctls numbers. Do you plan to take the block of ioctls
for future expansion? Do you plan to mix hfi's ioctls with verbs's ioctls
based on acceptance of new code?

> 
> >>In the interim, while the OFVWG is solidifying its one API to rule them
> >>all,
> >>this solves our current and very specific problem of treating
> >>write()/writev() differently.
> >
> >OFVWG is working on improving current verbs interface, for proprietary things like this,
> >there is agreed API which will look similar to this:
> 
> As far as I know there has been no patches posted or real on-list review of
> this API as of yet.

Right.

> 
> -Denny

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]