All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Semwal, Sumit" <sumit.semwal@ti.com>,
	Robert Morell <rmorell@nvidia.com>,
	Mauro Carvalho Chehab <mchehab@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, sumit.semwal@linaro.org,
	airlied@linux.ie, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Date: Wed, 18 Jan 2012 12:21:56 +0000	[thread overview]
Message-ID: <CAPM=9txEgGgbim5Gtz5=Cr5Mf3NrQCx0D=0dQu25gtPTzjSM7Q@mail.gmail.com> (raw)
In-Reply-To: <201201181214.12055.arnd@arndb.de>

On Wed, Jan 18, 2012 at 12:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 18 January 2012, Semwal, Sumit wrote:
>> On Wed, Jan 18, 2012 at 5:38 AM, 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.
>>
>> + Konrad, Arnd, Mauro: there were strong objections on using
>> EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I
>> suggest we first arrive at a consensus before merging this patch.
>
> We discussed this before. The reason for using EXPORT_SYMBOL_GPL here is
> that the interface is low-level and that it's meant to be used by
> subsystems that export user-level interface based on that and come
> with their own device driver interface, such as V4L or DRM.
>
> While there is an eternal debate over whether there should or should
> not be out of tree device drivers, I think there is very little to gain
> by allowing dma_buf to be used by out of tree *subsystems*.
> Further, a device driver that tries to use the interface but sits outside
> of the regular subsystems is a bad technical choice and we should not
> encourage those either.

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.

>From an X.org point of view it would be useful to end-users to allow
this sort of thing, nouveau is a good solution its just not going to
beat the binary driver in a lot of ways, just not sure whether I care
enough yet.

Dave.

WARNING: multiple messages have this Message-ID (diff)
From: Dave Airlie <airlied@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Semwal, Sumit" <sumit.semwal@ti.com>,
	Robert Morell <rmorell@nvidia.com>,
	Mauro Carvalho Chehab <mchehab@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, sumit.semwal@linaro.org,
	airlied@linux.ie, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Date: Wed, 18 Jan 2012 12:21:56 +0000	[thread overview]
Message-ID: <CAPM=9txEgGgbim5Gtz5=Cr5Mf3NrQCx0D=0dQu25gtPTzjSM7Q@mail.gmail.com> (raw)
In-Reply-To: <201201181214.12055.arnd@arndb.de>

On Wed, Jan 18, 2012 at 12:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 18 January 2012, Semwal, Sumit wrote:
>> On Wed, Jan 18, 2012 at 5:38 AM, 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.
>>
>> + Konrad, Arnd, Mauro: there were strong objections on using
>> EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I
>> suggest we first arrive at a consensus before merging this patch.
>
> We discussed this before. The reason for using EXPORT_SYMBOL_GPL here is
> that the interface is low-level and that it's meant to be used by
> subsystems that export user-level interface based on that and come
> with their own device driver interface, such as V4L or DRM.
>
> While there is an eternal debate over whether there should or should
> not be out of tree device drivers, I think there is very little to gain
> by allowing dma_buf to be used by out of tree *subsystems*.
> Further, a device driver that tries to use the interface but sits outside
> of the regular subsystems is a bad technical choice and we should not
> encourage those either.

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.

From an X.org point of view it would be useful to end-users to allow
this sort of thing, nouveau is a good solution its just not going to
beat the binary driver in a lot of ways, just not sure whether I care
enough yet.

Dave.

  reply	other threads:[~2012-01-18 12:21 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-06 15:06 [git pull] dma-buf tree Dave Airlie
2012-01-08 22:08 ` Linus Torvalds
2012-01-09  6:44   ` Sumit Semwal
2012-01-13  9:08     ` Dave Airlie
2012-01-13  9:38       ` Sumit Semwal
2012-01-13  9:40         ` 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 [this message]
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
2012-01-18 11:53   ` Expanding the use of DMA buffers in 3.3 Alan Cox
2012-01-18 11:53     ` Alan Cox
2012-01-19  6:43   ` Pekka Enberg
2012-01-19  6:43     ` Pekka Enberg
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
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-16 21:22       ` Robert Morell
2012-10-17  9:53         ` Alan Cox
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

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='CAPM=9txEgGgbim5Gtz5=Cr5Mf3NrQCx0D=0dQu25gtPTzjSM7Q@mail.gmail.com' \
    --to=airlied@gmail.com \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=rmorell@nvidia.com \
    --cc=sumit.semwal@linaro.org \
    --cc=sumit.semwal@ti.com \
    /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.