Daniel Vetter <daniel@xxxxxxxx> 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:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
