All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Packard <keithp@keithp.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-kernel@vger.kernel.org, Dave Airlie <airlied@redhat.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm: Add four ioctls for managing drm mode object leases
Date: Sun, 02 Apr 2017 09:44:58 -0700	[thread overview]
Message-ID: <861stakbcl.fsf@hiro.keithp.com> (raw)
In-Reply-To: <20170402132356.pgqzokifall7zjzy@phenom.ffwll.local>

[-- 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 --]

  reply	other threads:[~2017-04-02 16:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01 17:08 [PATCH 0/4] drm: Add mode resource leasing Keith Packard
2017-04-01 17:08 ` [PATCH 1/4] drm: Add new LEASE debug level Keith Packard
2017-04-01 17:08 ` [PATCH 2/4] drm: Add drm_object lease infrastructure Keith Packard
2017-04-02 13:38   ` Daniel Vetter
2017-04-02 13:38     ` Daniel Vetter
2017-04-02 16:31     ` Keith Packard
2017-04-10  5:16       ` Michel Dänzer
2017-04-10  5:16         ` Michel Dänzer
2017-04-02 17:51   ` Daniel Vetter
2017-04-02 17:51     ` Daniel Vetter
2017-04-02 19:59     ` Keith Packard
2017-04-01 17:08 ` [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths Keith Packard
2017-04-02 13:19   ` Daniel Vetter
2017-04-02 13:19     ` Daniel Vetter
2017-04-02 16:37     ` Keith Packard
2017-04-03  7:49       ` Daniel Vetter
2017-04-03  7:49         ` Daniel Vetter
2017-04-10  1:06     ` Keith Packard
2017-04-10  1:06       ` Keith Packard
2017-04-01 17:08 ` [PATCH 4/4] drm: Add four ioctls for managing drm mode object leases Keith Packard
2017-04-02 13:23   ` Daniel Vetter
2017-04-02 13:23     ` Daniel Vetter
2017-04-02 16:44     ` Keith Packard [this message]
2017-04-29  6:06 ` [PATCH 0/5] drm: Add mode resource leasing [v2] Keith Packard
2017-04-29  6:06   ` Keith Packard
2017-04-29  6:06   ` [PATCH 1/5] drm: Pass struct drm_file * to __drm_mode_object_find Keith Packard
2017-04-29  6:06     ` Keith Packard
2017-04-29  6:06   ` [PATCH 2/5] drm: Add new LEASE debug level Keith Packard
2017-04-29  6:06     ` Keith Packard
2017-04-29  6:07   ` [PATCH 3/5] drm: Add drm_object lease infrastructure [v2] Keith Packard
2017-04-29  6:07     ` Keith Packard
2017-04-29  6:07   ` [PATCH 4/5] drm: Check mode object lease status in all master ioctl paths [v2] Keith Packard
2017-04-29  6:07     ` Keith Packard
2017-04-29  6:07   ` [PATCH 5/5] drm: Add three ioctls for managing drm mode object leases [v2] Keith Packard
2017-04-29  6:07     ` Keith Packard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=861stakbcl.fsf@hiro.keithp.com \
    --to=keithp@keithp.com \
    --cc=airlied@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.