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:	Wed, 18 Jan 2012 14:39:59 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Ilija Hadzic <ihadzic@...earch.bell-labs.com>
Cc:	Dave Airlie <airlied@...il.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	Robert Morell <rmorell@...dia.com>, sumit.semwal@...aro.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

On Wednesday 18 January 2012, Ilija Hadzic wrote:
> On Wed, 18 Jan 2012, Dave Airlie wrote:
> 
> >
> > The problem is the x86 nvidia binary driver does sit outside of
> > subsystems, and I forsee wanting to share buffers with it from the
> > Intel driver in light of the optimus hardware. Although nouveau exists
> > and I'd much rather nvidia get behind that wrt the kernel stuff, I
> > don't forsee that happening.
> >

A lot of good stuff is coming out of nvidia these days regarding for
their tegra ARM socs. I wouldn't be surprised to see them in the same
boat as Intel and AMD regarding their support for free drivers in
the near future and I think it's worth supporting the people inside
of nvidia that are fighting for that instead of the others that are
against it.

Having more interesting features in nouveau that are not in the
proprietary driver would probably help on that front, too.

> Frankly, I never understood this "low-level interface" argument that is 
> kicked around when EXPORT_SYMBOL_GPL topic is brought up. My view to 
> EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL is that it really boils down to 
> license controversy about binary/proprietary modules in Linux kernel. To 
> me it's about whether the authors of certain code (for mostly 
> phylosophical reasons) agree that their (GPL) code is OK or not OK to link 
> against non-GPL module.

The controversy is about whether a module is a derived work of the kernel
when you link it in. Traditionally, some modules were not considered
derived works by a lot of people arguing that we have a public module
interface that acts as a barrier for the license in the same way that
the syscall interface lets you run proprietary applications.

The EXPORT_SYMBOL_GPL is all about symbols that are too low-level
to be considered part of that public module API (assuming that this
API exists). The argument is that symbols which are not meant to be
used in third-party modules can never be a license barrier and
anything using them is a derived work even if you consider other
modules not to be a derived work of the kernel. Note that this
argument can still hold for low-level symbols that are marked as
EXPORT_SYMBOL, using EXPORT_SYMBOL_GPL just makes it explicit.

	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/