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.
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.
In other words, being cautious is great, but without references of misuse it's very hard for others to draw the full picture.
I'm really sad that amdgpu insists on standing out, hope one day it will converge. Yet since all other maintainers are ok with the series, I'll start merging patches in a few hours. I'm really sad that amdgpu wants to stand out, hope it will converge sooner rather than later.
Christian, how would you like amdgpu handled - with a separate flag in the driver or shall we special case amdgpu within core drm?
No, I ask you to please stick around DRM_AUTH for at least amdgpu and radeon. And NOT enable any render node functionality for them on the primary node.
My question is how do you want this handled:
- DRM_PLEASE_FORCE_AUTH - added to AMDGPU/RADEON, or
- driver_name == amdgpu, in core DRM.
I want to keep DRM_AUTH in amdgpu and radeon for at least the next 5-10 years.
Believe we're all fully aware of that fact. I'm asking which _approach_ you prefer. That said, I'll send a new patch/series and we'll nitpick it there.
Thanks -Emil