All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 05/19] drm: move dev_mapping to the minor node
Date: Mon, 30 Apr 2012 19:04:28 +0100	[thread overview]
Message-ID: <CAPM=9twaEpiXSY_Dd7jLcNC6q6v9vBJhFnN-Q4AD2cbMggFaPg@mail.gmail.com> (raw)
In-Reply-To: <CAPM=9tyYxrzUOAqJUv1wpDGn0N3WwbdjBuxAHXDVeBxf+qMDEQ@mail.gmail.com>

On Mon, Apr 30, 2012 at 6:53 PM, Dave Airlie <airlied@gmail.com> wrote:
>>
>> Do you have pointers to that discussion (assuming it was on sime mailing
>> list)? The least I can do, while I am at it, is try to understand it and
>> see if I can incorporate some ideas from there in the rework of the patch.
>
> Nope it was an offhand discussion on irc while we were talking about
> some other ugly code.

Okay I think it was the code in coda,

       if (coda_inode->i_mapping == &coda_inode->i_data)
                coda_inode->i_mapping = host_inode->i_mapping;

        /* only allow additional mmaps as long as userspace isn't changing
         * the container file on us! */
        else if (coda_inode->i_mapping != host_inode->i_mapping) {
                spin_unlock(&cii->c_lock);
                return -EBUSY;
        }

We could use code like that to change the i_mapping, instead of failing.

Dave.

  reply	other threads:[~2012-04-30 18:04 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-12 18:19 [RFC v2] Revive the work on render-nodes branch 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 [this message]
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
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='CAPM=9twaEpiXSY_Dd7jLcNC6q6v9vBJhFnN-Q4AD2cbMggFaPg@mail.gmail.com' \
    --to=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ihadzic@research.bell-labs.com \
    --subject='Re: [PATCH 05/19] drm: move dev_mapping to the minor node' \
    /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.