[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <867f32kbyx.fsf@hiro.keithp.com>
Date: Sun, 02 Apr 2017 09:31:34 -0700
From: Keith Packard <keithp@...thp.com>
To: Daniel Vetter <daniel@...ll.ch>
Cc: linux-kernel@...r.kernel.org, Dave Airlie <airlied@...hat.com>,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 2/4] drm: Add drm_object lease infrastructure
Daniel Vetter <daniel@...ll.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
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists