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

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Jun 21, 2019 at 01:00:17PM +0000, Koenig, Christian wrote:
> 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.

From an upstream kernel pov I've never cared about the blobs. I don't
upstream should terribly start caring about blobs - if they ship hacks
that don't reflect what the open stack does, their problem.
 
Speaking as someone who's pissed off closed source driver teams to no end.
I'm happy to be of service here too :-)

> 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.

Jokes aside, I think we should look at what's the right thing to do
looking at open source only, and if that gets the blobby folks shafted,
well so be it. Really not my problem, and I'm pretty sure Dave doesn't
care one hair of an inch more.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel