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