> Unlikely as most of the code I've written belongs to Intel or Red Hat. I
> also have better things to do with life than sue Nvidia and start an all
> out copyright and patent war in Linuxspace.
I forgot to ask, but after your petty G+ trolling, if most of the code
belings to Intel or Red Hat,
Unlikely as most of the code I've written belongs to Intel or Red Hat. I
also have better things to do with life than sue Nvidia and start an all
out copyright and patent war in Linuxspace.
I forgot to ask, but after your petty G+ trolling, if most of the code
belings to Intel or Red Hat, why
> From the fact this patch keeps getting resubmitted despite repeated
> objection I deduce they are in fact of the view it does matter and that
> therefore it is a licensing change and they are scared of the
> consequences of ignoring it.
>
No I think they just want to have to write a pointless
On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox wrote:
>> > Please go and discuss estoppel, wilful infringement and re-licensing with
>> > your corporate attorneys. If you want to relicense components of the code
>> > then please take the matter up with the corporate attorneys of the rights
>> >
b>>
>> Alan please stick with the facts. This isn't a relicense of anything.
>> EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a
>> totally pointless thing, it should be
>> EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it
>> really should be EXPORT_SYMBOL, and
>> Please go and discuss estoppel, wilful infringement and re-licensing with
>> your corporate attorneys. If you want to relicense components of the code
>> then please take the matter up with the corporate attorneys of the rights
>> holders concerned.
>
> Alan please stick with the facts. This
On Wed, Oct 17, 2012 at 7:53 PM, Alan Cox wrote:
>> I believe that the developers and maintainers of dma-buf have provided
>> the needed signoff, both in person and in this thread. If there are any
>> objections from that group, I'm happy to discuss any changes necessary to get
>> this merged.
>
On Wed, 17 Oct 2012 20:22:04 +1000
Dave Airlie wrote:
> On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox wrote:
> >> > Please go and discuss estoppel, wilful infringement and re-licensing with
> >> > your corporate attorneys. If you want to relicense components of the code
> >> > then please take the
> > Please go and discuss estoppel, wilful infringement and re-licensing with
> > your corporate attorneys. If you want to relicense components of the code
> > then please take the matter up with the corporate attorneys of the rights
> > holders concerned.
>
> Alan please stick with the facts.
> I believe that the developers and maintainers of dma-buf have provided
> the needed signoff, both in person and in this thread. If there are any
> objections from that group, I'm happy to discuss any changes necessary to get
> this merged.
You need the permission of the owners of all the
I believe that the developers and maintainers of dma-buf have provided
the needed signoff, both in person and in this thread. If there are any
objections from that group, I'm happy to discuss any changes necessary to get
this merged.
You need the permission of the owners of all the dependant
On Wed, Oct 17, 2012 at 7:53 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
I believe that the developers and maintainers of dma-buf have provided
the needed signoff, both in person and in this thread. If there are any
objections from that group, I'm happy to discuss any changes necessary to get
Please go and discuss estoppel, wilful infringement and re-licensing with
your corporate attorneys. If you want to relicense components of the code
then please take the matter up with the corporate attorneys of the rights
holders concerned.
Alan please stick with the facts. This isn't a
b
Alan please stick with the facts. This isn't a relicense of anything.
EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a
totally pointless thing, it should be
EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it
really should be EXPORT_SYMBOL, and really consult
Please go and discuss estoppel, wilful infringement and re-licensing with
your corporate attorneys. If you want to relicense components of the code
then please take the matter up with the corporate attorneys of the rights
holders concerned.
Alan please stick with the facts. This isn't a
On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Please go and discuss estoppel, wilful infringement and re-licensing with
your corporate attorneys. If you want to relicense components of the code
then please take the matter up with the corporate attorneys of the
On Wed, 17 Oct 2012 20:22:04 +1000
Dave Airlie airl...@gmail.com wrote:
On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Please go and discuss estoppel, wilful infringement and re-licensing with
your corporate attorneys. If you want to relicense components of the
From the fact this patch keeps getting resubmitted despite repeated
objection I deduce they are in fact of the view it does matter and that
therefore it is a licensing change and they are scared of the
consequences of ignoring it.
No I think they just want to have to write a pointless hack
On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote:
> On Wed October 10 2012 23:02:06 Rob Clark wrote:
> > On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox
> > wrote:
> > > On Wed, 10 Oct 2012 08:56:32 -0700
> > > Robert Morell wrote:
> > >
> > >> EXPORT_SYMBOL_GPL is intended to be used for
On Wed, Oct 10, 2012 at 11:57:15PM -0700, Hans Verkuil wrote:
On Wed October 10 2012 23:02:06 Rob Clark wrote:
On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is
> > Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
> > calling into it anyway can't they. Your argument makes no rational sense
> > of any kind.
>
> But then why object to the change, your objection makes sense, naking
> the patch makes none, if you believe in your objection.
On Thu, Oct 11, 2012 at 9:34 PM, Alan Cox wrote:
>> The whole purpose of this API is to let DRM and V4L drivers share buffers for
>> zero-copy pipelines. Unfortunately it is a fact that several popular DRM
>> drivers
>> are closed source. So we have a choice between keeping the export symbols
Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and
calling into it anyway can't they. Your argument makes no rational sense
of any kind.
But then why object to the change, your objection makes sense, naking
the patch makes none, if you believe in your objection.
[l/k added
Hi Hans,
On Thursday 11 October 2012 13:36:45 Hans Verkuil wrote:
> On Thu 11 October 2012 13:34:07 Alan Cox wrote:
> > > The whole purpose of this API is to let DRM and V4L drivers share
> > > buffers for zero-copy pipelines. Unfortunately it is a fact that
> > > several popular DRM drivers are
On Thu 11 October 2012 13:36:45 Hans Verkuil wrote:
> On Thu 11 October 2012 13:34:07 Alan Cox wrote:
> > > The whole purpose of this API is to let DRM and V4L drivers share buffers
> > > for
> > > zero-copy pipelines. Unfortunately it is a fact that several popular DRM
> > > drivers
> > > are
On Thu 11 October 2012 13:34:07 Alan Cox wrote:
> > The whole purpose of this API is to let DRM and V4L drivers share buffers
> > for
> > zero-copy pipelines. Unfortunately it is a fact that several popular DRM
> > drivers
> > are closed source. So we have a choice between keeping the export
>> On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox
>> wrote:
>> > On Wed, 10 Oct 2012 08:56:32 -0700
>> > Robert Morell wrote:
>> >
>> >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> >> issue, and not really an interface". The dma-buf infrastructure is
>> >> explicitly
> > So, developers implicitly or explicitly copied in this thread that might be
> > considering the usage of dmabuf on proprietary drivers should consider
> > this email as a formal notification of my viewpoint: e. g. that I consider
> > any attempt of using DMABUF or media core/drivers together
> The whole purpose of this API is to let DRM and V4L drivers share buffers for
> zero-copy pipelines. Unfortunately it is a fact that several popular DRM
> drivers
> are closed source. So we have a choice between keeping the export symbols GPL
> and forcing those closed-source drivers to make
> As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your
> statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking)
Yes. The GPL talks about derivative works (as does copyright law).
Alan
Em Thu, 11 Oct 2012 08:47:15 -0500
Rob Clark escreveu:
> On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab
> wrote:
> > Em Thu, 11 Oct 2012 09:20:12 +0200
> > Hans Verkuil escreveu:
> >
> >> > my understaning is
> >> > that the drivers/media/ authors should also ack with this licensing
>
Op 11-10-12 09:51, Hans Verkuil schreef:
>>> my understaning is
>>> that the drivers/media/ authors should also ack with this licensing
>>> (possible) change. I am one of the main contributors there. Alan also has
>>> copyrights there, and at other parts of the Linux Kernel, including the
>>>
On Thu 11 October 2012 09:20:12 Hans Verkuil wrote:
> On Thu October 11 2012 03:11:19 Mauro Carvalho Chehab wrote:
> > Em Thu, 11 Oct 2012 09:22:34 +1000
> > Dave Airlie escreveu:
> >
> > > On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox
> > > wrote:
> > > > On Wed, 10 Oct 2012 08:56:32 -0700
> > >
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox wrote:
> On Wed, 10 Oct 2012 08:56:32 -0700
> Robert Morell wrote:
>
>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> issue, and not really an interface". The dma-buf infrastructure is
>> explicitly intended as an interface
On Thu October 11 2012 03:11:19 Mauro Carvalho Chehab wrote:
> Em Thu, 11 Oct 2012 09:22:34 +1000
> Dave Airlie escreveu:
>
> > On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox
> > wrote:
> > > On Wed, 10 Oct 2012 08:56:32 -0700
> > > Robert Morell wrote:
> > >
> > >> EXPORT_SYMBOL_GPL is intended
On Wed October 10 2012 23:02:06 Rob Clark wrote:
> On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox wrote:
> > On Wed, 10 Oct 2012 08:56:32 -0700
> > Robert Morell wrote:
> >
> >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> >> issue, and not really an interface". The
On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab
wrote:
> Em Thu, 11 Oct 2012 09:20:12 +0200
> Hans Verkuil escreveu:
>
>> > my understaning is
>> > that the drivers/media/ authors should also ack with this licensing
>> > (possible) change. I am one of the main contributors there. Alan
Em Thu, 11 Oct 2012 09:20:12 +0200
Hans Verkuil escreveu:
> > my understaning is
> > that the drivers/media/ authors should also ack with this licensing
> > (possible) change. I am one of the main contributors there. Alan also has
> > copyrights there, and at other parts of the Linux Kernel,
On Wed October 10 2012 23:02:06 Rob Clark wrote:
On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not
On Thu October 11 2012 03:11:19 Mauro Carvalho Chehab wrote:
Em Thu, 11 Oct 2012 09:22:34 +1000
Dave Airlie airl...@gmail.com escreveu:
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com wrote:
On Thu 11 October 2012 09:20:12 Hans Verkuil wrote:
On Thu October 11 2012 03:11:19 Mauro Carvalho Chehab wrote:
Em Thu, 11 Oct 2012 09:22:34 +1000
Dave Airlie airl...@gmail.com escreveu:
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk
wrote:
On Wed, 10 Oct
Op 11-10-12 09:51, Hans Verkuil schreef:
my understaning is
that the drivers/media/ authors should also ack with this licensing
(possible) change. I am one of the main contributors there. Alan also has
copyrights there, and at other parts of the Linux Kernel, including the
driver's
core,
So, developers implicitly or explicitly copied in this thread that might be
considering the usage of dmabuf on proprietary drivers should consider
this email as a formal notification of my viewpoint: e. g. that I consider
any attempt of using DMABUF or media core/drivers together with
On Thu 11 October 2012 13:34:07 Alan Cox wrote:
The whole purpose of this API is to let DRM and V4L drivers share buffers
for
zero-copy pipelines. Unfortunately it is a fact that several popular DRM
drivers
are closed source. So we have a choice between keeping the export symbols
On Thu 11 October 2012 13:36:45 Hans Verkuil wrote:
On Thu 11 October 2012 13:34:07 Alan Cox wrote:
The whole purpose of this API is to let DRM and V4L drivers share buffers
for
zero-copy pipelines. Unfortunately it is a fact that several popular DRM
drivers
are closed source. So
Hi Hans,
On Thursday 11 October 2012 13:36:45 Hans Verkuil wrote:
On Thu 11 October 2012 13:34:07 Alan Cox wrote:
The whole purpose of this API is to let DRM and V4L drivers share
buffers for zero-copy pipelines. Unfortunately it is a fact that
several popular DRM drivers are closed
Em Thu, 11 Oct 2012 09:20:12 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
my understaning is
that the drivers/media/ authors should also ack with this licensing
(possible) change. I am one of the main contributors there. Alan also has
copyrights there, and at other parts of the Linux
On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em Thu, 11 Oct 2012 09:20:12 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
my understaning is
that the drivers/media/ authors should also ack with this licensing
(possible) change. I am one of the main
On Thu, Oct 11, 2012 at 9:34 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
The whole purpose of this API is to let DRM and V4L drivers share buffers for
zero-copy pipelines. Unfortunately it is a fact that several popular DRM
drivers
are closed source. So we have a choice between keeping the
Em Thu, 11 Oct 2012 08:47:15 -0500
Rob Clark robdcl...@gmail.com escreveu:
On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em Thu, 11 Oct 2012 09:20:12 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
my understaning is
that the drivers/media/ authors
Em Thu, 11 Oct 2012 09:22:34 +1000
Dave Airlie escreveu:
> On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox wrote:
> > On Wed, 10 Oct 2012 08:56:32 -0700
> > Robert Morell wrote:
> >
> >> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> >> issue, and not really an
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell wrote:
> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface". The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL
On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox wrote:
> On Wed, 10 Oct 2012 08:56:32 -0700
> Robert Morell wrote:
>
>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> issue, and not really an interface". The dma-buf infrastructure is
>> explicitly intended as an interface
Em Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell escreveu:
> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface". The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use
EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
issue, and not really an interface". The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should use EXPORT_SYMBOL instead.
Signed-off-by: Robert Morell
---
This patch is based
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should use EXPORT_SYMBOL instead.
Signed-off-by: Robert Morell rmor...@nvidia.com
---
This
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should use
Em Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com escreveu:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
Em Thu, 11 Oct 2012 09:22:34 +1000
Dave Airlie airl...@gmail.com escreveu:
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Wed, 10 Oct 2012 08:56:32 -0700
Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal
On Tue, Jan 17, 2012 at 6:08 PM, Robert Morell wrote:
> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface". ?The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL
On Tue, Jan 17, 2012 at 6:08 PM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should use
> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
> symbols can be used by the binary blobs, possibly with an open-sourced
> shim which provides the buffer-sharing interface to the binary blobs?
> Are there any reasons to not consider this approach?
The GPL requires all the
Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu:
> Em 25-01-2012 10:30, Alan Cox escreveu:
>>> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
>>> symbols can be used by the binary blobs, possibly with an open-sourced
>>> shim which provides the buffer-sharing interface to
Em 25-01-2012 10:30, Alan Cox escreveu:
>> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
>> symbols can be used by the binary blobs, possibly with an open-sourced
>> shim which provides the buffer-sharing interface to the binary blobs?
>> Are there any reasons to not consider
On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter wrote:
> On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
>> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
>> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell
>> > wrote:
>> > > EXPORT_SYMBOL_GPL is intended to be
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary blobs?
Are there any reasons to not consider this approach?
The GPL requires all the code of
Em 25-01-2012 10:30, Alan Cox escreveu:
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary blobs?
Are there any reasons to not consider this
Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu:
Em 25-01-2012 10:30, Alan Cox escreveu:
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed
symbols can be used by the binary blobs, possibly with an open-sourced
shim which provides the buffer-sharing interface to the binary
On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell
> > wrote:
> > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > > issue, and not really
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
explicitly
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell
> > wrote:
> > > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > > issue, and not really
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote:
> > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > issue, and not really an interface". ?The dma-buf infrastructure is
> > explicitly intended as an
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote:
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote:
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not
On Wed, Jan 18, 2012 at 12:23 PM, Mauro Carvalho Chehab
wrote:
> Em 18-01-2012 10:14, Arnd Bergmann escreveu:
>> On Wednesday 18 January 2012, Semwal, Sumit wrote:
>>> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell
>>> wrote:
EXPORT_SYMBOL_GPL is intended to be used for "an internal
On Wed, Jan 18, 2012 at 06:00:54AM -0800, Dave Airlie wrote:
> On Wed, Jan 18, 2012 at 1:55 PM, 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
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote:
> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface". ?The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL
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
On Wed, Jan 18, 2012 at 1:55 PM, 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.
On Wed, Jan 18, 2012 at 12:14 PM, Arnd Bergmann wrote:
> On Wednesday 18 January 2012, Semwal, Sumit wrote:
>> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote:
>> > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>> > issue, and not really an interface". ?The
On Wednesday 18 January 2012, Semwal, Sumit wrote:
> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote:
> > EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> > issue, and not really an interface". The dma-buf infrastructure is
> > explicitly intended as an interface
On Tue, 17 Jan 2012 16:08:17 -0800
Robert Morell wrote:
> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
> issue, and not really an interface". The dma-buf infrastructure is
> explicitly intended as an interface between modules/drivers, so it
> should use EXPORT_SYMBOL
Em 18-01-2012 10:14, Arnd Bergmann escreveu:
> On Wednesday 18 January 2012, Semwal, Sumit wrote:
>> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell wrote:
>>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>>> issue, and not really an interface". The dma-buf
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
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should use
On Wed, Jan 18, 2012 at 12:14 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 18 January 2012, Semwal, Sumit wrote:
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an
On Wed, Jan 18, 2012 at 1:55 PM, Ilija Hadzic
ihad...@research.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
Em 18-01-2012 10:14, Arnd Bergmann escreveu:
On Wednesday 18 January 2012, Semwal, Sumit wrote:
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf
On Wed, Jan 18, 2012 at 12:23 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 18-01-2012 10:14, Arnd Bergmann escreveu:
On Wednesday 18 January 2012, Semwal, Sumit wrote:
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell rmor...@nvidia.com wrote:
EXPORT_SYMBOL_GPL is intended to be used
EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
issue, and not really an interface". The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should use EXPORT_SYMBOL instead.
Signed-off-by: Robert Morell
---
EXPORT_SYMBOL_GPL is intended to be used for an internal implementation
issue, and not really an interface. The dma-buf infrastructure is
explicitly intended as an interface between modules/drivers, so it
should use EXPORT_SYMBOL instead.
Signed-off-by: Robert Morell rmor...@nvidia.com
---
94 matches
Mail list logo
