On Sun, Apr 02, 2017 at 09:37:16AM -0700, Keith Packard wrote: > Daniel Vetter <daniel@xxxxxxxx> writes: > > > I think it'd be good if we could consolidate all the lease checking into > > drm_mode_object_find (respectively __drm_mode_object_find). We'd need to > > wire up the fpriv to be able to do that, but we could upstream that patch > > right away before anything else. That should take care of most of the > > checks in this patch here. > > That's a good idea. > > > There's a few things on top: > > - filtering the various bitmasks. I think you have most, but we could > > perhaps upstream the helpers for these. > > Yeah, would be nice to get hooks in place soon to avoid rebase > adventures later. I guess that would involve shipping a stub drm_lease.h > for now? I think we should see how far wiring drm_file *fpriv through the lookup functions gets us, but yeah we probably need a stub drm_lease.h for filtering. For the interface maybe pass a drm_file *fpriv for all the filtering functions, and deref into fpriv->master or whatever on the implementation. That gives us all the freedom to filter however we want really. > > - filtering object lists (essentially getresources and getplanes ioctls). > > - filtering implicit objects in the legacy ioctl. E.g. page_flip done > > through atomic doesn't just need the CRTC id, but also the id of the > > primary plane plus of the FB_ID atomic property. Similarly for all the > > other legacy ioctls. I think we want to make sure there's no difference > > here in behaviour. > > Oh, all of the implicit resource access from the legacy ioctls. Yeah, > that will take a bit of research to identify all of them. > > > Especially for the last one it might be simplest to outright disallow all > > legacy ioctl and require that sub-drm_master nodes only get access to the > > read-only GET* ioctl (they get that anyway, even when they're not the > > current master), plus atomic. Makes it a _lot_ easier to implement. > > Downside is that amdgpu _really_ needs to land atomic asap :-) > > I'd like to avoid that particular dependency as amdgpu is something of a > requirement for this particular project... Figured so :-) Otoh I've heard that atomic for amdgpu is happening for real now. Although Harry told me I need to wait a few more weeks before they're ready to present the rewritten stuff and get my feedback ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
