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