mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ilija Hadzic <ihadzic@research.bell-labs.com>
To: Dave Airlie <airlied@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	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 07:55:34 -0600 (CST)	[thread overview]
Message-ID: <Pine.GSO.4.62.1201180733450.26200@umail> (raw)
In-Reply-To: <CAPM=9txEgGgbim5Gtz5=Cr5Mf3NrQCx0D=0dQu25gtPTzjSM7Q@mail.gmail.com>




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.
>

Please correct me if I blab a nonsense here, but just the other day, we 
have seen a different thread in which it was decided that user cannot turn 
on buffer sharing at compile time explicitly, but rather a driver that 
needs it would turn it on automatically.

Doesn't that alone exclude out-of-tree drivers? In other words if you have 
two out-of-tree drivers that want to use DMA buffer sharing, and no other 
enabled driver in the kernel enables it implicitly, then such a kernel 
won't make it possible for said two drivers to work.

On a related note, EXPORT_SYMBOL_GPL will still happily link with 
out-of-tree driver, for as long as that driver comes under GPL-compatible 
license. So it's not really a question of whether the driver is 
out-of-tree or in-tree, but it's a question of driver's license.

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.

>From that angle, I am not sure if it is ethical at all to modify how the 
symbol is exported without explicit consent of the original author 
(regardless of what we think about GPL/proprietary modules covtroversy). 
So if NVidia needs to link DMA buffer sharing against their proprietary 
driver, they should have explicit permission from the original author to 
turn its symbols into EXPORT_SYMBOL.

-- Ilija


  reply	other threads:[~2012-01-18 14:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.DEB.2.00.1201061458020.18430@skynet.skynet.ie>
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 13:55           ` Ilija Hadzic [this message]
2012-01-18 14:00             ` Dave Airlie
2012-01-19  1:11               ` Robert Morell
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 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-19  6:43   ` Pekka Enberg

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=Pine.GSO.4.62.1201180733450.26200@umail \
    --to=ihadzic@research.bell-labs.com \
    --cc=airlied@gmail.com \
    --cc=arnd@arndb.de \
    --cc=dri-devel@lists.freedesktop.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®