From: "Michel Dänzer" <michel@daenzer.net>
To: Emil Velikov <emil.l.velikov@gmail.com>,
"Koenig, Christian" <Christian.Koenig@amd.com>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
David Airlie <airlied@linux.ie>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Date: Fri, 21 Jun 2019 17:24:25 +0200 [thread overview]
Message-ID: <38e0da2b-829a-3aa8-b25f-e10662ada099@daenzer.net> (raw)
In-Reply-To: <20190621115845.GC21486@arch-x1c3>
On 2019-06-21 1:58 p.m., Emil Velikov wrote:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 12:53 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
>
>>>>> 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.
That may be the case with userspace specific to DRM_AUTH-less kernel
drivers, but such userspace couldn't work with all the other drivers. So
I'd argue that while the bag may be open and the cat's tail may even be
sticking out already, the cat is still firmly in the bag. :)
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-06-21 15:24 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-27 8:17 [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround Emil Velikov
[not found] ` <20190527081741.14235-1-emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-05-27 8:17 ` [PATCH 02/13] drm/amdgpu: drop DRM_AUTH usage from the driver Emil Velikov
2019-05-27 8:17 ` [PATCH 10/13] drm/radeon: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls Emil Velikov
2019-05-27 10:47 ` [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround Koenig, Christian
[not found] ` <3c9b5688-5e83-f173-00e3-6e139e05d466-5C7GfCeVMHo@public.gmane.org>
2019-05-27 12:05 ` Emil Velikov
2019-05-27 12:20 ` Koenig, Christian
2019-05-27 12:52 ` Emil Velikov
2019-05-27 13:26 ` Daniel Vetter
2019-05-27 13:34 ` Daniel Vetter
2019-05-27 13:20 ` Daniel Vetter
[not found] ` <20190527132041.GP21222-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-05-27 13:26 ` Emil Velikov
2019-05-27 13:42 ` Koenig, Christian
[not found] ` <0426fb3e-e7bc-2464-cb42-4d5753956d23-5C7GfCeVMHo@public.gmane.org>
2019-05-27 15:26 ` Daniel Vetter
[not found] ` <CAKMK7uE_pRro8PxTwUq+pC_1GVVT7nUxan1T-kqSYT=BMHTf2g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-28 6:58 ` Koenig, Christian
[not found] ` <d12a7dd4-595b-d0aa-a87d-527392fb0384-5C7GfCeVMHo@public.gmane.org>
2019-05-28 7:38 ` Daniel Vetter
[not found] ` <CAKMK7uE1ZWjCeg3q7qDrbcj89+DuPQwfjMqC8hTjDAMU5bhh-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-28 8:03 ` Koenig, Christian
[not found] ` <98c3d891-6966-2043-9709-4e718dbc6bac-5C7GfCeVMHo@public.gmane.org>
2019-05-28 8:18 ` Daniel Vetter
[not found] ` <CAKMK7uGsc7WzBBrfxape4Yy7fbKoDFH5J2F87Kx=7rE1+pXcXw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-28 16:10 ` Emil Velikov
2019-05-28 16:22 ` Koenig, Christian
2019-05-28 16:46 ` Emil Velikov
2019-05-28 20:05 ` Dave Airlie
[not found] ` <CAPM=9tzuQX4iQU=w4QfbE1ryq6sXc4k5SVh6V1_4AyH_O+D_oA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-05-29 13:03 ` Emil Velikov
2019-05-29 13:14 ` Koenig, Christian
2019-05-29 16:29 ` Emil Velikov
2019-05-31 12:20 ` Koenig, Christian
2019-06-04 17:59 ` Emil Velikov
2019-06-04 10:50 ` Michel Dänzer
[not found] ` <ee1b8980-3d78-aa6d-fe46-2c0d45c2bbdd-otUistvHUpPR7s880joybQ@public.gmane.org>
2019-06-04 11:24 ` Koenig, Christian
2019-06-04 13:28 ` Daniel Vetter
2019-05-27 15:32 ` Emil Velikov
2019-05-27 13:11 ` Daniel Vetter
[not found] ` <20190527131143.GN21222-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2019-05-27 13:47 ` Emil Velikov
2019-06-14 12:09 ` Emil Velikov
2019-06-14 12:55 ` Koenig, Christian
[not found] ` <9dbdda6c-8916-e5ae-1676-86828b9890e7-5C7GfCeVMHo@public.gmane.org>
2019-06-14 14:16 ` Michel Dänzer
2019-06-14 15:53 ` Emil Velikov
2019-06-14 16:00 ` Koenig, Christian
[not found] ` <84b3337c-0cdc-44d4-02c6-c56bd729ed47-5C7GfCeVMHo@public.gmane.org>
2019-06-14 16:25 ` Emil Velikov
2019-06-20 16:30 ` Emil Velikov
2019-06-21 7:12 ` Koenig, Christian
[not found] ` <9cad6e74-4751-0b0a-35d1-e8f0ac4d3efc-5C7GfCeVMHo@public.gmane.org>
2019-06-21 7:41 ` Michel Dänzer
2019-06-21 8:23 ` Koenig, Christian
2019-06-21 9:09 ` Daniel Vetter
2019-06-21 9:25 ` Koenig, Christian
[not found] ` <be9f38f5-6bb5-9535-f3d9-bafa83370e0f-5C7GfCeVMHo@public.gmane.org>
2019-06-21 9:35 ` Daniel Vetter
[not found] ` <CAKMK7uE5qO4q3RYNDp22gkMSSJGgz9ChxhuWPYqXO6D1UUvy6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-21 10:16 ` Christian König
2019-06-21 10:20 ` Emil Velikov
2019-06-21 10:31 ` Koenig, Christian
[not found] ` <d241fab3-b6f0-d38a-b83f-03b70736b355-5C7GfCeVMHo@public.gmane.org>
2019-06-21 10:53 ` Emil Velikov
2019-06-21 11:07 ` Koenig, Christian
[not found] ` <338bb519-05f1-cb76-d965-81237f432937-5C7GfCeVMHo@public.gmane.org>
2019-06-21 11:58 ` Emil Velikov
2019-06-21 12:13 ` Koenig, Christian
[not found] ` <76158d1f-676d-2afa-244b-934967a9cb75-5C7GfCeVMHo@public.gmane.org>
2019-06-21 12:47 ` Emil Velikov
2019-06-21 13:00 ` Koenig, Christian
2019-06-21 15:37 ` Daniel Vetter
2019-06-21 15:24 ` Michel Dänzer [this message]
2019-06-21 11:03 ` Daniel Vetter
[not found] ` <CAKMK7uEVziNZJES9=JFBUu=LpmubS8=-A654cMN+QqhEmc8Fvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-21 11:37 ` Christian König
[not found] ` <c92dc683-6815-dc5a-dc2b-54517cc027de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-06-21 11:50 ` Daniel Vetter
[not found] ` <CAKMK7uHsv3HOXOQq=GGRkx6f+ssRg7dO7qEoBqRS9V_KiTN3Hg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-21 11:59 ` Daniel Vetter
[not found] ` <CAKMK7uG+EUhmZafFmjzSR=eq7543OELbHVaQnZZQGx0APSozwg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-21 12:01 ` Emil Velikov
2019-06-21 15:15 ` Michel Dänzer
[not found] ` <b182c8e3-c060-71f0-2b3b-62600d825c9f-otUistvHUpPR7s880joybQ@public.gmane.org>
2019-06-21 15:44 ` Daniel Vetter
2019-06-21 15:52 ` Michel Dänzer
[not found] ` <13024821-4767-eeaf-86eb-9ae1056f8931-otUistvHUpPR7s880joybQ@public.gmane.org>
2019-06-24 9:37 ` Michel Dänzer
[not found] ` <b03e8977-c51a-9606-383f-cf4ba674dcdd-otUistvHUpPR7s880joybQ@public.gmane.org>
2019-06-24 9:48 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38e0da2b-829a-3aa8-b25f-e10662ada099@daenzer.net \
--to=michel@daenzer.net \
--cc=Alexander.Deucher@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=airlied@linux.ie \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox