From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilija Hadzic Subject: Re: [PATCH 05/19] drm: move dev_mapping to the minor node Date: Tue, 15 May 2012 15:48:13 -0500 (CDT) Message-ID: References: <1334254784-3200-1-git-send-email-ihadzic@research.bell-labs.com> <1334254784-3200-6-git-send-email-ihadzic@research.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by gabe.freedesktop.org (Postfix) with ESMTP id 75E979E94A for ; Tue, 15 May 2012 13:48:15 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Dave Airlie Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Mon, 30 Apr 2012, Dave Airlie wrote: > On Mon, Apr 30, 2012 at 6:53 PM, Dave Airlie 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. > I have just cut (and sent to the list) a patch that, I believe, implements this idea. I did it slightly differently from what coda fs does, but it's the same concept. I set i_mapping in the open() instead of moving it down to mmap(), because there are so many variants of mmap both in drm and GPU-specific drivers, that it would get too messy. I traced the code quite extensively with printks and it looks like it's doing the right thing. If the new patch seems right, then if and when we add render nodes, the original dev_mapping patch that started this thread won't be needed any more. -- Ilija