From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL Date: Sat, 21 Jan 2012 18:32:07 +0100 Message-ID: <20120121173207.GF3821@phenom.ffwll.local> References: <1326845297-6233-1-git-send-email-rmorell@nvidia.com> <1326845297-6233-2-git-send-email-rmorell@nvidia.com> <20120120180457.GE29824@morell.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20120120180457.GE29824@morell.nvidia.com> Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org To: Robert Morell Cc: "Semwal, Sumit" , Mauro Carvalho Chehab , Arnd Bergmann , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "sumit.semwal@linaro.org" List-Id: dri-devel@lists.freedesktop.org On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote: > On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: > > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell = wrote: > > > EXPORT_SYMBOL_GPL is intended to be used for "an internal impleme= ntation > > > issue, and not really an interface". =A0The dma-buf infrastructur= e is > > > explicitly intended as an interface between modules/drivers, so i= t > > > should use EXPORT_SYMBOL instead. > >=20 > > + Konrad, Arnd, Mauro: there were strong objections on using > > EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I > > suggest we first arrive at a consensus before merging this patch. >=20 > This discussion seems to have stagnated; how do we move forward here? >=20 > Sumit, as the primary author and new maintainer (congrats!) of the > dma-buf infrastructure, it seems like it's really your call how to > proceed. I'd still like to see this be something that we can use fro= m > the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave h= ave > argued in this thread. It really seems to me that this change on a > technical level won't have any adverse effect on the scenarios where = it > can be used today, but it will allow it to be used more widely, which > will prevent duplication and fragmentation in the future and be great= ly > appreciated by users of hardware such as Optimus. Given that I've participated quite a bit in the design of dma_buf as-is= , let me throw in my totally irrelevant opinion, too ;-) I'll refrain from comment on the actual patch, it's obviously a hot top= ic. =46urthermore I might need to ask Intel's legal dep for guidance to ass= es things wrt my own contributions to dma_buf. Otoh I'd like nvidia to be on board, especially when we're desingned additions to dma_buf required to make it really work for multiple gpus.= In additions it looks like that the nvidia blob will only be an importer o= f a dma_buf, at least for the use-cases discussed here. So why don't you just ditch this patch here and add a small shim to you= r blob to interface with drm's prime as an importing driver? I personally would deem that acceptable and I think Dave wouldn't mind too much, either. Yours, Daniel Disclaimer: This is my own opinion and I do not speak as an Intel emplo= yee here. --=20 Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48