From: Arnd Bergmann <arnd@arndb.de>
To: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Dave Airlie <airlied@gmail.com>,
Mauro Carvalho Chehab <mchehab@redhat.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Robert Morell <rmorell@nvidia.com>,
sumit.semwal@linaro.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Date: Wed, 18 Jan 2012 14:39:59 +0000 [thread overview]
Message-ID: <201201181439.59338.arnd@arndb.de> (raw)
In-Reply-To: <Pine.GSO.4.62.1201180733450.26200@umail>
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
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>,
Robert Morell <rmorell@nvidia.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
sumit.semwal@linaro.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Date: Wed, 18 Jan 2012 14:39:59 +0000 [thread overview]
Message-ID: <201201181439.59338.arnd@arndb.de> (raw)
In-Reply-To: <Pine.GSO.4.62.1201180733450.26200@umail>
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
next prev parent reply other threads:[~2012-01-18 14:40 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-06 15:06 [git pull] dma-buf tree Dave Airlie
2012-01-08 22:08 ` Linus Torvalds
2012-01-09 6:44 ` Sumit Semwal
2012-01-13 9:08 ` Dave Airlie
2012-01-13 9:38 ` Sumit Semwal
2012-01-13 9:40 ` Dave Airlie
2012-01-18 0:08 ` Expanding the use of DMA buffers in 3.3 Robert Morell
2012-01-18 0:08 ` [PATCH] dma-buf: Use EXPORT_SYMBOL Robert Morell
2012-01-18 9:10 ` Semwal, Sumit
2012-01-18 12:14 ` Arnd Bergmann
2012-01-18 12:21 ` Dave Airlie
2012-01-18 12:21 ` Dave Airlie
2012-01-18 13:55 ` Ilija Hadzic
2012-01-18 13:55 ` Ilija Hadzic
2012-01-18 14:00 ` Dave Airlie
2012-01-19 1:11 ` Robert Morell
2012-01-18 14:39 ` Arnd Bergmann [this message]
2012-01-18 14:39 ` Arnd Bergmann
2012-01-18 12:23 ` Mauro Carvalho Chehab
2012-01-19 7:26 ` Dave Airlie
2012-01-20 18:04 ` Robert Morell
2012-01-20 18:12 ` Konrad Rzeszutek Wilk
2012-01-21 17:32 ` Daniel Vetter
2012-01-25 5:34 ` Semwal, Sumit
2012-01-25 12:30 ` Alan Cox
2012-01-25 12:30 ` Alan Cox
2012-01-25 13:46 ` Mauro Carvalho Chehab
2012-01-25 13:48 ` Mauro Carvalho Chehab
2012-01-18 11:48 ` Alan Cox
2012-02-19 21:20 ` Rob Clark
2012-01-18 11:53 ` Expanding the use of DMA buffers in 3.3 Alan Cox
2012-01-18 11:53 ` Alan Cox
2012-01-19 6:43 ` Pekka Enberg
2012-01-19 6:43 ` Pekka Enberg
2012-10-10 15:56 [PATCH] dma-buf: Use EXPORT_SYMBOL Robert Morell
2012-10-10 15:56 ` Robert Morell
2012-10-10 16:23 ` Mauro Carvalho Chehab
2012-10-10 16:23 ` Mauro Carvalho Chehab
2012-10-10 18:17 ` Alan Cox
2012-10-10 21:02 ` Rob Clark
2012-10-11 6:57 ` Hans Verkuil
2012-10-11 6:57 ` Hans Verkuil
2012-10-11 11:34 ` Alan Cox
2012-10-11 11:34 ` Alan Cox
2012-10-11 11:36 ` Hans Verkuil
2012-10-11 12:10 ` Hans Verkuil
2012-10-11 12:52 ` Laurent Pinchart
2012-10-16 21:22 ` Robert Morell
2012-10-17 9:53 ` Alan Cox
2012-10-10 23:22 ` Dave Airlie
2012-10-11 1:11 ` Mauro Carvalho Chehab
2012-10-11 2:50 ` Dave Airlie
2012-10-11 11:37 ` Alan Cox
2012-10-11 7:20 ` Hans Verkuil
2012-10-11 7:51 ` Hans Verkuil
2012-10-11 9:10 ` Maarten Lankhorst
2012-10-11 11:13 ` Mauro Carvalho Chehab
2012-10-11 13:47 ` Rob Clark
2012-10-11 14:55 ` Mauro Carvalho Chehab
2012-10-11 11:30 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201201181439.59338.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ihadzic@research.bell-labs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@redhat.com \
--cc=rmorell@nvidia.com \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.