From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [PATCH v2] drm: enable render-nodes by default Date: Fri, 21 Mar 2014 09:29:31 +0100 Message-ID: <532BF86B.7030101@vmware.com> References: <1394977400-10465-1-git-send-email-dh.herrmann@gmail.com> <1395074636-32337-1-git-send-email-dh.herrmann@gmail.com> <532A8E07.5000208@shipmail.org> <532AAB78.6010500@vmware.com> <532AB481.40309@vmware.com> <532AC2C2.5030606@vmware.com> <532B557F.2050904@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by gabe.freedesktop.org (Postfix) with ESMTP id C85A26E277 for ; Fri, 21 Mar 2014 01:29:37 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 03/21/2014 08:10 AM, Daniel Vetter wrote: > On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark wrote: >>>> Ie. an app that was using the gpu for something secure could >>>> simply choose not to if the hw/driver could not guarantee that another >>>> process using the gpu could not get access to the buffers.. >>> IMO that should work fine, but we need to provide a way for user-space >>> to determine whether >>> the render node is secure or not. Perhaps a sysfs attribute and / or a >>> drm getparam() parameter? >> I'd *assume* that that sort of thing would just be some sort of CL extension? >> >> But no objection to exposing it in a more common way. >> >> I guess it is also an option to keep the bootarg to override default >> (with the default being 'enabled' for hw w/ per-context/process vm and >> 'disabled' otherwise). > Imo if we expose this through sysfs we should always enable > rendernodes. The udev scripts can then decide what permissions to set > on them. Agreed. Thomas > -Daniel