From: Hans Verkuil <hverkuil@xs4all.nl>
To: Rob Clark <rob@ti.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Robert Morell <rmorell@nvidia.com>,
linaro-mm-sig@lists.linaro.org,
Sumit Semwal <sumit.semwal@linaro.org>,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Date: Thu, 11 Oct 2012 08:57:15 +0200 [thread overview]
Message-ID: <201210110857.15660.hverkuil@xs4all.nl> (raw)
In-Reply-To: <CAF6AEGvzfr2-QHpX4zwm2EPz-vxCDe9SaLUjo4_Fn7HhjWJFsg@mail.gmail.com>
On Wed October 10 2012 23:02:06 Rob Clark wrote:
> On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Wed, 10 Oct 2012 08:56:32 -0700
> > Robert Morell <rmorell@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 EXPORT_SYMBOL instead.
> >
> > NAK. This needs at the very least the approval of all rights holders for
> > the files concerned and all code exposed by this change.
>
> Well, for my contributions to dmabuf, I don't object.. and I think
> because we are planning to use dma-buf in userspace for dri3 /
> dri-next, I think that basically makes it a userspace facing kernel
> infrastructure which would be required for open and proprietary
> drivers alike. So I don't see much alternative to making this
> EXPORT_SYMBOL(). Of course, IANAL.
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 their own incompatible API,
thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
the closed source vendors worry about the legality. They are already using such
functions (at least nvidia is), so they clearly accept that risk.
I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse
evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL
limitation. Neither situation is paradise, but at least one is a slightly less
depressing world than the other :-)
In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did not
do any coding but only some initial design help and reviewing.
Regards,
Hans
WARNING: multiple messages have this Message-ID (diff)
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Rob Clark <rob@ti.com>
Cc: dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
Sumit Semwal <sumit.semwal@linaro.org>,
linux-media@vger.kernel.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Date: Thu, 11 Oct 2012 08:57:15 +0200 [thread overview]
Message-ID: <201210110857.15660.hverkuil@xs4all.nl> (raw)
In-Reply-To: <CAF6AEGvzfr2-QHpX4zwm2EPz-vxCDe9SaLUjo4_Fn7HhjWJFsg@mail.gmail.com>
On Wed October 10 2012 23:02:06 Rob Clark wrote:
> On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Wed, 10 Oct 2012 08:56:32 -0700
> > Robert Morell <rmorell@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 EXPORT_SYMBOL instead.
> >
> > NAK. This needs at the very least the approval of all rights holders for
> > the files concerned and all code exposed by this change.
>
> Well, for my contributions to dmabuf, I don't object.. and I think
> because we are planning to use dma-buf in userspace for dri3 /
> dri-next, I think that basically makes it a userspace facing kernel
> infrastructure which would be required for open and proprietary
> drivers alike. So I don't see much alternative to making this
> EXPORT_SYMBOL(). Of course, IANAL.
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 their own incompatible API,
thus defeating the whole point of DMABUF, or using EXPORT_SYMBOL and letting
the closed source vendors worry about the legality. They are already using such
functions (at least nvidia is), so they clearly accept that risk.
I prefer the evil where the DMABUF API uses EXPORT_SYMBOL to prevent the worse
evil where an incompatible API is created to work around the EXPORT_SYMBOL_GPL
limitation. Neither situation is paradise, but at least one is a slightly less
depressing world than the other :-)
In other words, I'm OK with EXPORT_SYMBOL for whatever it is worth as I did not
do any coding but only some initial design help and reviewing.
Regards,
Hans
next prev parent reply other threads:[~2012-10-11 6:58 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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-11 20:08 ` [Linaro-mm-sig] " Dave Airlie
2012-10-12 16:32 ` Alan Cox
2012-10-25 21:30 ` Dave Airlie
2012-10-16 21:22 ` Robert Morell
2012-10-17 9:53 ` Alan Cox
2012-10-17 9:54 ` [Linaro-mm-sig] " Dave Airlie
2012-10-17 10:08 ` Dave Airlie
2012-10-17 10:19 ` Dave Airlie
2012-10-17 10:25 ` Alan Cox
2012-10-17 10:22 ` Dave Airlie
2012-10-17 10:38 ` Alan Cox
2012-10-17 10:40 ` Dave Airlie
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
-- strict thread matches above, loose matches on Subject: below --
2012-01-06 15:06 [git pull] dma-buf tree 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
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
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=201210110857.15660.hverkuil@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=rmorell@nvidia.com \
--cc=rob@ti.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.