* [PATCH 0/1] DRM IOCTL permission change
@ 2015-09-15 8:11 Thomas Hellstrom
2015-09-15 8:11 ` [PATCH] drm: Allow also control clients to check the drm version Thomas Hellstrom
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Hellstrom @ 2015-09-15 8:11 UTC (permalink / raw)
To: dri-devel
A minor IOCTL permission change for control clients. If there are no
objections I'd like to add this to the next vmwgfx -fixes pull request.
Thanks,
Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] drm: Allow also control clients to check the drm version
2015-09-15 8:11 [PATCH 0/1] DRM IOCTL permission change Thomas Hellstrom
@ 2015-09-15 8:11 ` Thomas Hellstrom
2015-09-16 14:35 ` David Herrmann
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Hellstrom @ 2015-09-15 8:11 UTC (permalink / raw)
To: dri-devel; +Cc: Thomas Hellstrom
This should be harmless.
Vmware will, due to old infrastructure reasons, be using a privileged
control client to supply GUI layout information rather than obtaining
it from the device. That control client will be needing access to DRM
version information.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
---
drivers/gpu/drm/drm_ioctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 9a860ca..d93e737 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -520,7 +520,8 @@ EXPORT_SYMBOL(drm_ioctl_permit);
/** Ioctl table */
static const struct drm_ioctl_desc drm_ioctls[] = {
- DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid, DRM_MASTER|DRM_ROOT_ONLY),
--
2.1.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] drm: Allow also control clients to check the drm version
2015-09-15 8:11 ` [PATCH] drm: Allow also control clients to check the drm version Thomas Hellstrom
@ 2015-09-16 14:35 ` David Herrmann
2015-09-16 15:03 ` Thomas Hellstrom
0 siblings, 1 reply; 5+ messages in thread
From: David Herrmann @ 2015-09-16 14:35 UTC (permalink / raw)
To: Thomas Hellstrom; +Cc: dri-devel@lists.freedesktop.org
Hi
On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom
<thellstrom@vmware.com> wrote:
> This should be harmless.
> Vmware will, due to old infrastructure reasons, be using a privileged
> control client to supply GUI layout information rather than obtaining
> it from the device. That control client will be needing access to DRM
> version information.
I didn't add it to render-nodes as I wasn't aware of any driver still
using the version-information. I'm not a big fan on relying on magic
numbers, as it doesn't work well with (stable) backports, but if you
need it for backwards-compat on vmwgfx, I'm fine with it. But I
certainly don't want to encourage new driver authors to use it.
> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
> Reviewed-by: Brian Paul <brianp@vmware.com>
> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
> ---
> drivers/gpu/drm/drm_ioctl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 9a860ca..d93e737 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -520,7 +520,8 @@ EXPORT_SYMBOL(drm_ioctl_permit);
>
> /** Ioctl table */
> static const struct drm_ioctl_desc drm_ioctls[] = {
> - DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
> + DRM_UNLOCKED|DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW),
Why the line-break? None of the other ioctl definitions cares for the
80ch limit. I'd prefer keeping this uniform.
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Thanks
David
> DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
> DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
> DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid, DRM_MASTER|DRM_ROOT_ONLY),
> --
> 2.1.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] drm: Allow also control clients to check the drm version
2015-09-16 14:35 ` David Herrmann
@ 2015-09-16 15:03 ` Thomas Hellstrom
2015-09-16 18:08 ` David Herrmann
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Hellstrom @ 2015-09-16 15:03 UTC (permalink / raw)
To: David Herrmann; +Cc: dri-devel@lists.freedesktop.org
Hi, David,
On 09/16/2015 04:35 PM, David Herrmann wrote:
> Hi
>
> On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom
> <thellstrom@vmware.com> wrote:
>> This should be harmless.
>> Vmware will, due to old infrastructure reasons, be using a privileged
>> control client to supply GUI layout information rather than obtaining
>> it from the device. That control client will be needing access to DRM
>> version information.
> I didn't add it to render-nodes as I wasn't aware of any driver still
> using the version-information.
In fact you did add it to render nodes (commit 3d3b78c), but this is for
control nodes.
> I'm not a big fan on relying on magic
> numbers, as it doesn't work well with (stable) backports, but if you
> need it for backwards-compat on vmwgfx, I'm fine with it. But I
> certainly don't want to encourage new driver authors to use it.
We view the driver version information as user-space api version
information, which I can't see changing
with stable backports (except perhaps in very unlikely situations).
Of course, there are other ways to signal feature availability, but
we've traditionally been checking version minor.
>
>> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
>> Reviewed-by: Brian Paul <brianp@vmware.com>
>> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
>> ---
>> drivers/gpu/drm/drm_ioctl.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> index 9a860ca..d93e737 100644
>> --- a/drivers/gpu/drm/drm_ioctl.c
>> +++ b/drivers/gpu/drm/drm_ioctl.c
>> @@ -520,7 +520,8 @@ EXPORT_SYMBOL(drm_ioctl_permit);
>>
>> /** Ioctl table */
>> static const struct drm_ioctl_desc drm_ioctls[] = {
>> - DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version, DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF(DRM_IOCTL_VERSION, drm_version,
>> + DRM_UNLOCKED|DRM_RENDER_ALLOW|DRM_CONTROL_ALLOW),
> Why the line-break? None of the other ioctl definitions cares for the
> 80ch limit. I'd prefer keeping this uniform.
OK, I'll fix that up.
>
> Acked-by: David Herrmann <dh.herrmann@gmail.com>
>
> Thanks
> David
Thanks,
Thomas
>
>> DRM_IOCTL_DEF(DRM_IOCTL_GET_UNIQUE, drm_getunique, 0),
>> DRM_IOCTL_DEF(DRM_IOCTL_GET_MAGIC, drm_getmagic, 0),
>> DRM_IOCTL_DEF(DRM_IOCTL_IRQ_BUSID, drm_irq_by_busid, DRM_MASTER|DRM_ROOT_ONLY),
>> --
>> 2.1.0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=BQIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=-dqJN9pZD2sav6M76SFMIM359ZWmPz3fLT0oU30MVRw&s=ICMYbx449lJwRcYDljH6Z8Zp9SQO6mX71E9Y9OgL_SA&e=
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] drm: Allow also control clients to check the drm version
2015-09-16 15:03 ` Thomas Hellstrom
@ 2015-09-16 18:08 ` David Herrmann
0 siblings, 0 replies; 5+ messages in thread
From: David Herrmann @ 2015-09-16 18:08 UTC (permalink / raw)
To: Thomas Hellstrom; +Cc: dri-devel@lists.freedesktop.org
Hi
On Wed, Sep 16, 2015 at 5:03 PM, Thomas Hellstrom <thellstrom@vmware.com> wrote:
> Hi, David,
>
> On 09/16/2015 04:35 PM, David Herrmann wrote:
>> Hi
>>
>> On Tue, Sep 15, 2015 at 10:11 AM, Thomas Hellstrom
>> <thellstrom@vmware.com> wrote:
>>> This should be harmless.
>>> Vmware will, due to old infrastructure reasons, be using a privileged
>>> control client to supply GUI layout information rather than obtaining
>>> it from the device. That control client will be needing access to DRM
>>> version information.
>> I didn't add it to render-nodes as I wasn't aware of any driver still
>> using the version-information.
>
> In fact you did add it to render nodes (commit 3d3b78c), but this is for
> control nodes.
Sorry, my bad. For control nodes is also fine.
Thanks
David
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-09-16 18:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-15 8:11 [PATCH 0/1] DRM IOCTL permission change Thomas Hellstrom
2015-09-15 8:11 ` [PATCH] drm: Allow also control clients to check the drm version Thomas Hellstrom
2015-09-16 14:35 ` David Herrmann
2015-09-16 15:03 ` Thomas Hellstrom
2015-09-16 18:08 ` David Herrmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.