Re: [PATCH 4/4] drm: Add four ioctls for managing drm mode object leases

Keith Packard
2017-04-02T16:45:02Z

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

Daniel Vetter <daniel@ffwll.ch> writes:

> Should we just use fd for this? Essentially lessors would be required to
> keep track of all their pending leases, and just dup() them over to the
> client. Would reduce the uapi scope a bit, and if a lessor can't keep
> track of it's leases there's a problem.

Right now, the lease terminates when the fd closes. If the lessor is
holding the fd open, it would have to have some out-of-band indication
that the lessee was done so that it could close its copy of the fd.

However, it's not clear what value these query APIs have for the lessor
in any case; surely it can remember what resources are in each lease
without needing a kernel API. For the lessee, this API provides a way of
learning about changes to the lease. That would mean getting rid of the
lessee id in the requests, which seems good.

I added them mostly to make checking the code easier during development;
it caught a nasty bug where I was smashing the lessor file_priv with the
lessee due to poor choice of variable names in the kernel code.

I was thinking this morning that the lessee would like to know not only
the ID but also the type of each resources so that it could figure out
how to use the lease.

I'll rewrite these to only return the resources for the fd provided, but
to return both id and type.

For listing lessees, I don't see value in allowing the lessor to look at
sub-leases made by the lessee, so I'll remove the lessor id from that
request and have it just return the list of lessees for the current lessor.

> For this one here we could pass the fd of the lease as the argument. I
> also still think that for v1 we just want revoke and otherwise invariant
> leases. Makes things simpler.

Again, that means that lessor would need to hold the lease fd open,
which makes it hard to know when the lessee is done. However, there's no
reason the lessor should be in control of the lessee's sub-leases, so
again, I propose to restrict the scope of lessees to those directly
under the lessor.

> Non-driver functions please into drm-internal.h, we don't want to let
> drivers even see this :-)

Thanks!

--
-keith

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]