[PATCH] dma-buf: Use EXPORT_SYMBOL
ihadzic at research.bell-labs.com
Wed Jan 18 05:55:34 PST 2012
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.
More information about the dri-devel