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

Doug Ledford
2016-05-24T17:57:54Z

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

On 05/24/2016 12:02 PM, Liran Liss wrote:
>> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
>> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Hefty, Sean
> ...
>>
>> The following is a sketch, or outline, for an ioctl framework.
>> The purpose of the patch is to drive discussion and feedback on various design
>> decisions rather than low-level comments on the code, so that the changes can
>> be incorporated earlier in the development cycle. The code is entirely untested
>> and some functionality is not coded.
>>
>
> This approach focuses on facilities for arbitrary device-specific objects (which could basically fit GPUs, NVMe, whatever...), while our primary goals are to replace write() with ioctl() and strive for a common *rdma* object model.

Please be precise when you use the word "our". In particular, I do not
count myself among your "our".

> In contrast, the patchset [1], focuses on the task at hand. The emphasis is on a common framework for parsing and parameter validation. It follows the agreed-upon

Again, precision is needed here. Agreed upon by whom? Not I, and
evidently not Sean either.

> concepts such as a single ioctl request code for common objects,

I'm not sure I agree with this as a priority.

> natural mapping of the existing object mode (and hence easier backporting),

Nor this.

> typed attributes for extending the objects to accommodate multiple vendor features, and a unique ioctl request code for vendor-specific commands.
> --Liran
>
> [1] http://permalink.gmane.org/gmane.linux.drivers.rdma/36984

While concalls to discuss these topics are handy, it is easy to miss
objections or alternative priorities.

So let me sum up how I see things.

First, we had a security issue that needed addressed. We did so with a
security check on the current ABI. During the discussions about that, I
specifically told Linus we wanted to address it that way for now so that
we could work on getting the verbs 2.0 API that addresses some of the
shortcomings of the current API out the door, but do it right and not
rush things. That verbs 2.0 API would fix the security issue up
completely where the security checks are no longer needed.

What we have today is a proposal to basically take the verbs 1.0 API and
convert it from write() to ioctl() with as little change as possible to
the API. This is what the patchset you referenced is all about, and
what you and Jason have been talking about. Allow me to be clear: this
is not verbs 2.0 API. This is verbs 1.0 over ioctl. Nothing more. And
it does nothing to fix up the shortcomings of the verbs 1.0 API that are
playing out right now in things like the timestamp pacthset.

Sean's proposal does away with the rigid nature of the current verbs 1.0
API and makes it much more flexible on a per-driver basis. This doesn't
address the end user API issues, but it at least cleans up the user
driver <-> kernel driver API so that one vendor's driver is not forced
to carry around all the baggage needed for every other vendor's drivers.

Under that model, each vendor only carries what they need. It would
then be libibverbs responsibility to take that driver specific data and
present it to the user in a generic way. The mechanism of that is not
yet known, but thinking about it is what prompted my email in the
"Further thoughts on uAPI" discussion, the one where I made the possible
wc processing example.

This is why I don't think it's possible to think about the verbs 2.0 API
and not also the user visible libibverbs API at the same time. If all
we want to talk about is verbs 1.0 over ioctl, then yes, we can do that.
But not if we truly want to discuss a verbs 2.0 API. And I have yet to
gather from the discussions I hear from people that we are in fact
decided on pursuing a verbs 1.0 over ioctl API instead of considering a
verbs 2.0 API. So please don't present things as though they are
settled. As far as I can tell, they very much are not.

--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: 0E572FDD

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]