[PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

Michel Dänzer michel at daenzer.net
Fri Jun 21 15:24:25 UTC 2019


On 2019-06-21 1:58 p.m., Emil Velikov wrote:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 12:53 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
> 
>>>>> In particular, that user-space will "remove" render nodes.
>>>> Yes, that is my main concern here. You basically make render nodes
>>>> superfluously. That gives userspace all legitimization to also remove
>>>> support for them. That is not stupid or evil or whatever, userspace
>>>> would just follow the kernel design.
>>>>
>>> Do you have an example of userspace doing such an extremely silly thing?
>>> It does seem like suspect you're a couple of steps beyond overcautious,
>>> perhaps rightfully so. Maybe you've seen some closed-source user-space
>>> going crazy? Or any other projects?
>>
>> The key point is that I don't think this is silly or strange or crazy at 
>> all. See the kernel defines the interface userspace can and should use.
>>
>> When the kernel defines that everything will work with the primary node 
>> it is perfectly valid for userspace to drop support for the render node.
>>
>> I mean why should they keep this? Just because we tell them not to do this?
>>
> From your experiense, do user-space developers care about doing (or
> generally do) the right thing?
> 
> In either case, as pointed already the cat is out of the bag - has been
> for years, and if developers did behave as you describe them they would
> have "removed" render nodes already.

That may be the case with userspace specific to DRM_AUTH-less kernel
drivers, but such userspace couldn't work with all the other drivers. So
I'd argue that while the bag may be open and the cat's tail may even be
sticking out already, the cat is still firmly in the bag. :)


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the amd-gfx mailing list