Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751234AbdDBQbi (ORCPT ); Sun, 2 Apr 2017 12:31:38 -0400 Received: from home.keithp.com ([63.227.221.253]:59719 "EHLO elaine.keithp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750861AbdDBQbh (ORCPT ); Sun, 2 Apr 2017 12:31:37 -0400 From: Keith Packard To: Daniel Vetter Cc: linux-kernel@vger.kernel.org, Dave Airlie , dri-devel@lists.freedesktop.org Subject: Re: [PATCH 2/4] drm: Add drm_object lease infrastructure In-Reply-To: <20170402133802.wgminf777ksczl76@phenom.ffwll.local> References: <20170401170841.2643-1-keithp@keithp.com> <20170401170841.2643-3-keithp@keithp.com> <20170402133802.wgminf777ksczl76@phenom.ffwll.local> Date: Sun, 02 Apr 2017 09:31:34 -0700 Message-ID: <867f32kbyx.fsf@hiro.keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2530 Lines: 64 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Daniel Vetter 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 stru= ct >> + * All of these get activated simultaneously, so drm_device master poi= nts > > &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. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAljhJ2YACgkQ2yIaaQAA ABGoUhAAmajYDEDmPA2HlYnF+aFRn2ArpU9GzTl9uMx0G0vS9bDxUuZtjW7ms4Ix HXBuwMuodkzTQsDU+ManLrhS3buCJshYCdj3WtJCqX8bmI9IC2qXEQ47myD00jXf PrmtYCwLj/ZCG0eoJaM3hjpjUnXjnDMxEGHczAs3iK1IKORCJLldQwgRL7alQq74 /jDbjElot6Lk4wKLYidoJV7Tlw9PO3nhNbp25K0QgiSDnYxPI4HhZ2ngjWUPZ8A0 6XP+1qRhvJLen66Kohf9aj25GdKDiH2qj1w3vZkWHGQgilj+UzViWZM5pQ5ugLBk +OoBJiTAmAX/YED9w0geVoWDK/3IIc7nAU8kIybJ/8BwhpuiZgE1wjsdVRboLhUE LJe4JO7m6/zU6P+VQsAWm2J6VibO32kDI2um5MAqfAo72h8DSz8dobJ6tIgyVN1w V9zLimpTyFIz+0cBH2u32NJgFMPVnkvxuLCkJHtuT9+U7vWUsIZ1DMXhDass88rU GNg4AKiJdX8wbHa75NG7Jzw+y3Pn5vVKwHw9kbO11AGSTmgv12MDsd1rSB/yQgp6 j8q1DNGY73+JW3mfTzjMxguEFh4o2dpZh43jbuuLC855zrmcDdGmzVqotFq5aQL7 0voHvvJdiaF//ZK/veZA1fqCoLYpU47FlmIZkqnxZy5lihdzK24= =/mFV -----END PGP SIGNATURE----- --=-=-=--