On Wed October 10 2012 23:02:06 Rob Clark wrote: > On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 10 Oct 2012 08:56:32 -0700 > > Robert Morell <rmorell@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
