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]

Message-ID: <CAPM=9twKT8V9b_g0vChiNGm_J0jVBgrnhJQjnNDD1QzOMp=aoQ@mail.gmail.com>
Date:	Wed, 18 Jan 2012 14:00:54 +0000
From:	Dave Airlie <airlied@...il.com>
To:	Ilija Hadzic <ihadzic@...earch.bell-labs.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	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 Wed, Jan 18, 2012 at 1:55 PM, Ilija Hadzic
<ihadzic@...earch.bell-labs.com> 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.
>>
>
> 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.

Well the use case at least on x86 would be open x86 driver sharing
with closed nvidia driver, if two closed drivers wanted to share I'd
except them to do it internally anyways.

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

Which is the point of their patch, to ask permission from the author.

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