linux-kernel - Re: [PATCH] dma-buf: Use EXPORT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Jan 2012 10:04:57 -0800
From:	Robert Morell <rmorell@...dia.com>
To:	"Semwal, Sumit" <sumit.semwal@...com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
	"airlied@...ux.ie" <airlied@...ux.ie>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell <rmorell@...dia.com> wrote:
> > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > issue, and not really an interface".  The dma-buf infrastructure is
> > explicitly intended as an interface between modules/drivers, so it
> > should use EXPORT_SYMBOL instead.
> 
> + 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.

This discussion seems to have stagnated; how do we move forward here?

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 from
the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have
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 greatly
appreciated by users of hardware such as Optimus.

Let me know if you have any questions.

Thanks,
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/