On Fri, Apr 20, 2012 at 11:20:45AM +0100, 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. My current plan to clean up the ioctl interface mess in drm/i915 is to start marking up any interfaces that userspace doesn't need any longer on a per-device level (already started on this). We can't drop the old support code, but this way we can at least stop supporting old interfaces on newer cards. The problem with that approach is that the drm middle-layer (hot topic today, I guess) gets in the way of this - we have to set the driver feature flags while registering the driver and can't change them when we initialize for a specific device. E.g. for i915 kms we need the old mapping interfaces and the agp support mess only on i945&g33 because we shipped horrible userspace that only works on these platforms (XvMC implementation fwiw). My plan there is to remove the middle-layer smell by moving the drm support subsystem initialization into the driver code. So imo we can solve 3) naturally by disabling old crap on new chips. No strong opinions on 1)&2), but sounds reasonable. Cheers, Daniel -- Daniel Vetter Mail: daniel@xxxxxxxx Mobile: +41 (0)79 365 57 48 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
