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

Koenig, Christian Christian.Koenig at amd.com
Fri Jun 21 13:00:17 UTC 2019


Am 21.06.19 um 14:47 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 13:58 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
>>>> Am 21.06.19 um 12:53 schrieb Emil Velikov:
>>>>> On 2019/06/21, Koenig, Christian wrote:
>>>>>> [SNIP]
>>>>>> Well partially. That RADV broke is unfortunate, but we have done so many
>>>>>> customized userspace stuff both based on Mesa/DDX as well as closed
>>>>>> source components that it is just highly likely that we would break
>>>>>> something else as well.
>>>>>>
>>>>> As an engineer I like to work with tangibles. The highly likely part is
>>>>> probable, but as mentioned multiple times the series allows for a _dead_
>>>>> trivial way to address any such problems.
>>>> Well to clarify my concern is that this won't be so trivial.
>>>>
>>>> You implemented on workaround for one specific case and it is perfectly
>>>> possible that for other cases we would have to completely revert the
>>>> removal of DRM_AUTH.
>>>>
>>> I would encourage you to take a closer look at my patch and point out
>>> how parcicular cases cannot be handled.
>> Well the last time I looked it only blocked the first call to the IOCTL.
>>
> Hmm interesting, you're replied to my patch without even reading it :'-(

Well I've NAKed the series because of the exposure of the render node 
functionality

> Can you please give it a close look and reply inline?
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/219238.html

So the workaround no longer just blocks the first IOCTL.

But then the question is why don't you just keep the DRM_AUTH flag 
instead of adding the same functionality with a new one?

>>>   From your experiense, do user-space developers care about doing (or
>>> generally do) the right thing?
>> No, not at all. Except for Marek and Michel they just take what works
>> and even Marek is often short-cutting on this.
>>
> Interesting, guess I should have asked this question from the start.

Well sounds like you don't have to work with a closed source driver 
team. But as I said I honestly would do the same as user space developer.

I mean it's really a bunch of more code to maintain, and getting rid of 
code is always less work in the long term then keeping it.

That kernel developers scream: No no, please don't do that we want to 
keep using it is completely irrelevant for this.

Christian.

>
> Thanks
> Emil



More information about the amd-gfx mailing list