On Sun, May 22, 2016 at 08:57:15PM +0300, Leon Romanovsky wrote:
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?
I'm still not sure what you are getting at here. Can you explain what you
mean by tensions over ioctl numbers? I guess I don't understand why the
hfi1_x device's use of icotl numbers has any bearing at all on the
ibcore/verbs ioctl(s).
If and when new code is accepted and hfi1 converges its API to go through a
common character device, then hfi1 would surely change to match whatever is
there whether that's a single ioctl with a command type embedded or
something that has not even yet been proposed.
-Denny
--
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
