On Fri, 20 Apr 2012, Dave Airlie wrote:
On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
<ihadzic@xxxxxxxxxxxxxxxxxxxxxx> wrote:
The following set of patches is the reword of the series
sent two weeks ago [2] that will revive the drm-render-nodes [1]
branch. Details of the original series are described in [2].
Thanks for looking at this,
So one thing about adding render nodes, is it gives us the chance to
maybe change the userspace API we expose to be more secure and have
less cruft in it.
Now I'm weary of a major API redesign as this could bog things now and
we'd never make forward progress, but I'd like to at least consider it
before adding new device nodes and locking us into the old APIs.
The areas suggested before:
1) GEM, drop flink/open ioctls - these make security hard, since once
you share a buffer any GEM opener can get access to it. Solutions to
this proposed before are flink_to and maybe using PRIME/dma-buf.
2) master/device ownership. We might be able to drop the first opener
is magically master, and require openers to ask for it somehow.
3) drop the old map ioctls from this interface, irq by busid, drop the AGP.
I'm not talking about changing ioctl operation, more about introducing
new ioctls and not allowing the old ones on the new nodes.
Dave.
Thanks for the feedback, point taken. So there will be some "homework" to
be done before you can take in the render nodes work. Would you be
perceptive to consider taking in some of the prep. patches that I sent in
my series? They will reduce the amount of baggage that needs to be carried
with actual render-nodes work and make it easier to keep it alive while
the above-proposed interface rework is being worked on.
For example, this one is just a simplification that makes
things more readable:
http://lists.freedesktop.org/archives/dri-devel/2012-April/021327.html
Then these two will make drm_mode_getplane_res more consistent with what
other getresources calls do (i.e., use drm_mode_group instead of
drm_mode_config).
http://lists.freedesktop.org/archives/dri-devel/2012-April/021328.html
http://lists.freedesktop.org/archives/dri-devel/2012-April/021329.html
This one won't hurt either and will make things look a little bit more
straightforward:
http://lists.freedesktop.org/archives/dri-devel/2012-April/021330.html
-- Ilija
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
