[PATCH 2/4] drm: Add drm_object lease infrastructure
Keith Packard
keithp at keithp.com
Sun Apr 2 16:31:34 UTC 2017
Daniel Vetter <daniel at ffwll.ch> writes:
> Still not sure we want to restrict objects on the lessor side. Feels like
> unecessary complexity (i.e. more bugs in kernel, that's never good), and
> at best only needed for lessors who can't keep track of stuff.
It's been useful when hacking existing code, and will help catch
application bugs. Limiting access to what you actually need always seems
like good practice to me.
> I'm also not sure whether we really want sub-leases in v1, that's easy
> to add later on, but for now just complicates stuff. Main compositor
> should be a full master, VR can be the first lease level, we don't
> need more I think for now?
We've discussed how leases might be used to implement multi-user
support, so offering sub-leases means that environment could also
support leasing resources out from the users session.
We also just don't know how useful it might be until we explore the
space a bit more. Given that it takes years to get new features into
distributions, I tend to error on the side of generality.
I think a key requirement for acceptance would be a set of robust tests,
something I haven't started writing yet.
>> + /* Tree of display resource leases, each of which is a drm_master struct
>> + * All of these get activated simultaneously, so drm_device master points
>
> &drm_device.master to do a reference in kernel-doc. Please feed this to
> kernel-doc in general and make sure the links all point at the right
> stuff, and it's all parsed.
Thanks, will do.
--
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170402/05f1443a/attachment.sig>
More information about the dri-devel
mailing list