All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC v2] Revive the work on render-nodes branch
Date: Fri, 20 Apr 2012 15:46:43 +0200	[thread overview]
Message-ID: <20120420134643.GG4217@phenom.ffwll.local> (raw)
In-Reply-To: <CAPM=9twv+6GB6Swg9C7NE6JvA=Rvm0u7cHRMOMrqbstHq-yyZQ@mail.gmail.com>

On Fri, Apr 20, 2012 at 11:20:45AM +0100, Dave Airlie wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
> <ihadzic@research.bell-labs.com> wrote:
> > The following set of patches is the reword of the series
> > sent two weeks ago [2] that will revive the drm-render-nodes [1]
> > branch. Details of the original series are described in [2].
> 
> Thanks for looking at this,
> 
> So one thing about adding render nodes, is it gives us the chance to
> maybe change the userspace API we expose to be more secure and have
> less cruft in it.
> 
> Now I'm weary of a major API redesign as this could bog things now and
> we'd never make forward progress, but I'd like to at least consider it
> before adding new device nodes and locking us into the old APIs.
> 
> The areas suggested before:
> 
> 1) GEM, drop flink/open ioctls - these make security hard, since once
> you share a buffer any GEM opener can get access to it. Solutions to
> this proposed before are flink_to and maybe using PRIME/dma-buf.
> 
> 2) master/device ownership. We might be able to drop the first opener
> is magically master, and require openers to ask for it somehow.
> 
> 3) drop the old map ioctls from this interface, irq by busid, drop the AGP.
> 
> I'm not talking about changing ioctl operation, more about introducing
> new ioctls and not allowing the old ones on the new nodes.

My current plan to clean up the ioctl interface mess in drm/i915 is to
start marking up any interfaces that userspace doesn't need any longer on
a per-device level (already started on this). We can't drop the old
support code, but this way we can at least stop supporting old interfaces
on newer cards.

The problem with that approach is that the drm middle-layer (hot topic
today, I guess) gets in the way of this - we have to set the driver
feature flags while registering the driver and can't change them when we
initialize for a specific device. E.g. for i915 kms we need the old
mapping interfaces and the agp support mess only on i945&g33 because we
shipped horrible userspace that only works on these platforms (XvMC
implementation fwiw).

My plan there is to remove the middle-layer smell by moving the drm
support subsystem initialization into the driver code. So imo we can solve
3) naturally by disabling old crap on new chips.

No strong opinions on 1)&2), but sounds reasonable.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-04-20 13:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12 18:19 Ilija Hadzic
2012-04-12 18:19 ` [PATCH 01/19] drm: simplify dereferencing of node type Ilija Hadzic
2012-04-12 18:19 ` [PATCH 02/19] drm: track planes in drm_mode_group structure Ilija Hadzic
2012-04-12 18:19 ` [PATCH 03/19] drm: use drm_mode_group in drm_mode_getplane_res Ilija Hadzic
2012-04-12 18:19 ` [PATCH 04/19] drm: do not push inode down into drm_open_helper Ilija Hadzic
2012-04-12 18:19 ` [PATCH 05/19] drm: move dev_mapping to the minor node Ilija Hadzic
2012-04-20 10:04   ` Dave Airlie
2012-04-30 14:48     ` Ilija Hadzic
2012-04-30 16:39       ` Dave Airlie
2012-04-30 16:52         ` Ilija Hadzic
2012-04-30 17:53           ` Dave Airlie
2012-04-30 18:04             ` Dave Airlie
2012-05-15 20:48               ` Ilija Hadzic
2012-04-12 18:19 ` [PATCH 06/19] drm: add support for render nodes Ilija Hadzic
2012-04-12 18:19 ` [PATCH 07/19] drm: initial multiple nodes ioctl work Ilija Hadzic
2012-04-20 10:15   ` Dave Airlie
2012-04-12 18:19 ` [PATCH 08/19] drm: separate render node descriptor from minor Ilija Hadzic
2012-04-12 18:19 ` [PATCH 09/19] drm: cleanup render node ioctls Ilija Hadzic
2012-04-12 18:19 ` [PATCH 10/19] drm: only allow render node ioctls through control node Ilija Hadzic
2012-04-12 18:19 ` [PATCH 11/19] drm: do not remove a render node in use Ilija Hadzic
2012-04-12 18:19 ` [PATCH 12/19] drm: allocate correct id_list size for a render node Ilija Hadzic
2012-04-12 18:19 ` [PATCH 13/19] drm: add drm_mode_group_fini function Ilija Hadzic
2012-04-12 18:19 ` [PATCH 14/19] drm: properly free id_list when a render node is removed Ilija Hadzic
2012-04-12 18:19 ` [PATCH 15/19] drm: call drm_mode_group_fini on primary node Ilija Hadzic
2012-04-12 18:19 ` [PATCH 16/19] drm: more elaborate check for resource count Ilija Hadzic
2012-04-12 18:19 ` [PATCH 17/19] drm: validate id list when creating a render node Ilija Hadzic
2012-04-12 18:19 ` [PATCH 18/19] drm: keep track of which node holds which resource Ilija Hadzic
2012-04-12 18:19 ` [PATCH 19/19] drm: hold mutex in critical sections of render-node code Ilija Hadzic
2012-04-12 18:55 ` [RFC v2] Revive the work on render-nodes branch Ville Syrjälä
2012-04-12 19:09   ` Ilija Hadzic
2012-04-20 10:20 ` Dave Airlie
2012-04-20 13:46   ` Daniel Vetter [this message]
2012-04-30 15:16   ` Ilija Hadzic
2012-04-30 19:01   ` Kristian Høgsberg

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=20120420134643.GG4217@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --subject='Re: [RFC v2] Revive the work on render-nodes branch' \
    /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

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.