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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
