Arnd Bergmann arnd at arndb.de
Wed Jan 18 06:39:59 PST 2012

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.


More information about the dri-devel mailing list