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]
Message-Id: <201201181214.12055.arnd@arndb.de>
Date:	Wed, 18 Jan 2012 12:14:11 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	"Semwal, Sumit" <sumit.semwal@...com>
Cc:	Robert Morell <rmorell@...dia.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	linux-kernel@...r.kernel.org, sumit.semwal@...aro.org,
	airlied@...ux.ie, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

On Wednesday 18 January 2012, 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.

We discussed this before. The reason for using EXPORT_SYMBOL_GPL here is
that the interface is low-level and that it's meant to be used by
subsystems that export user-level interface based on that and come
with their own device driver interface, such as V4L or DRM.

While there is an eternal debate over whether there should or should
not be out of tree device drivers, I think there is very little to gain
by allowing dma_buf to be used by out of tree *subsystems*.
Further, a device driver that tries to use the interface but sits outside
of the regular subsystems is a bad technical choice and we should not
encourage those either.

NAK

	Arnd
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ