Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
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 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. Thanks for the discussion. My intention is not to steal any code from the kernel or change any licenses. The goal here is to allow interoperation between drivers. I understand that it can be difficult to debug the kernel when the nvidia binary module is loaded; I'm not trying to force anyone to do that. You're free to continue to use your debug environment without change after this patch is applied. 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. - Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf: Use EXPORT_SYMBOL
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 patch is based on Linus's master branch. We held a discussion at ELC, and agreed that EXPORT_SYMBOL is more appropriate for this interface than EXPORT_SYMBOL_GPL. drivers/base/dma-buf.c | 34 +- 1 files changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 460e22d..24c28be 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -122,7 +122,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct dma_buf_ops *ops, return dmabuf; } -EXPORT_SYMBOL_GPL(dma_buf_export); +EXPORT_SYMBOL(dma_buf_export); /** @@ -148,7 +148,7 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags) return fd; } -EXPORT_SYMBOL_GPL(dma_buf_fd); +EXPORT_SYMBOL(dma_buf_fd); /** * dma_buf_get - returns the dma_buf structure related to an fd @@ -174,7 +174,7 @@ struct dma_buf *dma_buf_get(int fd) return file-private_data; } -EXPORT_SYMBOL_GPL(dma_buf_get); +EXPORT_SYMBOL(dma_buf_get); /** * dma_buf_put - decreases refcount of the buffer @@ -189,7 +189,7 @@ void dma_buf_put(struct dma_buf *dmabuf) fput(dmabuf-file); } -EXPORT_SYMBOL_GPL(dma_buf_put); +EXPORT_SYMBOL(dma_buf_put); /** * dma_buf_attach - Add the device to dma_buf's attachments list; optionally, @@ -234,7 +234,7 @@ err_attach: mutex_unlock(dmabuf-lock); return ERR_PTR(ret); } -EXPORT_SYMBOL_GPL(dma_buf_attach); +EXPORT_SYMBOL(dma_buf_attach); /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list; @@ -256,7 +256,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) mutex_unlock(dmabuf-lock); kfree(attach); } -EXPORT_SYMBOL_GPL(dma_buf_detach); +EXPORT_SYMBOL(dma_buf_detach); /** * dma_buf_map_attachment - Returns the scatterlist table of the attachment; @@ -283,7 +283,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, return sg_table; } -EXPORT_SYMBOL_GPL(dma_buf_map_attachment); +EXPORT_SYMBOL(dma_buf_map_attachment); /** * dma_buf_unmap_attachment - unmaps and decreases usecount of the buffer;might @@ -304,7 +304,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, attach-dmabuf-ops-unmap_dma_buf(attach, sg_table, direction); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); /** @@ -332,7 +332,7 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, return ret; } -EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access); +EXPORT_SYMBOL(dma_buf_begin_cpu_access); /** * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the @@ -354,7 +354,7 @@ void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len, if (dmabuf-ops-end_cpu_access) dmabuf-ops-end_cpu_access(dmabuf, start, len, direction); } -EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access); +EXPORT_SYMBOL(dma_buf_end_cpu_access); /** * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address @@ -371,7 +371,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf-ops-kmap_atomic(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic); +EXPORT_SYMBOL(dma_buf_kmap_atomic); /** * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic. @@ -389,7 +389,7 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf-ops-kunmap_atomic) dmabuf-ops-kunmap_atomic(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic); +EXPORT_SYMBOL(dma_buf_kunmap_atomic); /** * dma_buf_kmap - Map a page of the buffer object into kernel address space. The @@ -406,7 +406,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num) return dmabuf-ops-kmap(dmabuf, page_num); } -EXPORT_SYMBOL_GPL(dma_buf_kmap); +EXPORT_SYMBOL(dma_buf_kmap); /** * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap. @@ -424,7 +424,7 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, if (dmabuf-ops-kunmap) dmabuf-ops-kunmap(dmabuf, page_num, vaddr); } -EXPORT_SYMBOL_GPL(dma_buf_kunmap); +EXPORT_SYMBOL(dma_buf_kunmap); /** @@ -466,7 +466,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, return dmabuf-ops-mmap(dmabuf, vma); } -EXPORT_SYMBOL_GPL(dma_buf_mmap); +EXPORT_SYMBOL(dma_buf_mmap); /** * dma_buf_vmap - Create virtual mapping for the buffer object into kernel @@ -487,7 +487,7
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote: On Monday 12 December 2011, Robert Morell wrote: Doing a buffer sharing with something that is not GPL is not fun, as, if any issue rises there, it would be impossible to discover if the problem is either at the closed-source driver or at the open source one. At the time I was using the Nvidia proprietary driver, it was very common to have unexplained issues caused likely by bad code there at the buffer management code, causing X applications and extensions (like xv) to break. We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter debug future share buffer issues, when needed. Sorry, I don't buy this argument. Making these exports GPL-only is not likely to cause anybody to open-source their driver, but will rather just cause them to use yet more closed-source code that is even less debuggable than this would be, to those without access to the source. But at least the broken module then won't be interacting with other modules because it cannot share any buffers. One of the goals of this project is to unify the fragmented space of the ARM SoC memory managers so that each vendor doesn't implement their own, and they can all be closer to mainline. I fear that restricting the use of this buffer sharing mechanism to GPL drivers only will prevent that goal from being achieved, if an SoC driver has to interact with modules that use a non-GPL license. As a hypothetical example, consider laptops that have multiple GPUs. Today, these ship with onboard graphics (integrated to the CPU or chipset) along with a discrete GPU, where in many cases only the onboard graphics can actually display to the screen. In order for anything rendered by the discrete GPU to be displayed, it has to be copied to memory available for the smaller onboard graphics to texture from or display directly. Obviously, that's best done by sharing dma buffers rather than bouncing them through the GPU. It's not much of a stretch to imagine that we'll see such systems with a Tegra CPU/GPU plus a discrete GPU in the future; in that case, we'd want to be able to share memory between the discrete GPU and the Tegra system. In that scenario, if this interface is GPL-only, we'd be unable to adopt the dma_buffer sharing mechanism for Tegra. (This isn't too pie-in-the-sky, either; people are already combining Tegra with discrete GPUs: http://blogs.nvidia.com/2011/11/world%e2%80%99s-first-arm-based-supercomputer-to-launch-in-barcelona/ ) Thanks, Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote: On 09-12-2011 20:50, Robert Morell wrote: On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: On Friday 02 December 2011, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. [...] + return dmabuf; +} +EXPORT_SYMBOL(dma_buf_export); I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, because it's really a low-level function that I would expect to get used by in-kernel subsystems providing the feature to users and having back-end drivers, but it's not the kind of thing we want out-of-tree drivers to mess with. Is this really necessary? If this is intended to be a lowest-common-denominator between many drivers to allow buffer sharing, it seems like it needs to be able to be usable by all drivers. If the interface is not accessible then I fear many drivers will be forced to continue to roll their own buffer sharing mechanisms (which is exactly what we're trying to avoid here, needless to say). Doing a buffer sharing with something that is not GPL is not fun, as, if any issue rises there, it would be impossible to discover if the problem is either at the closed-source driver or at the open source one. At the time I was using the Nvidia proprietary driver, it was very common to have unexplained issues caused likely by bad code there at the buffer management code, causing X applications and extensions (like xv) to break. We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter debug future share buffer issues, when needed. Sorry, I don't buy this argument. Making these exports GPL-only is not likely to cause anybody to open-source their driver, but will rather just cause them to use yet more closed-source code that is even less debuggable than this would be, to those without access to the source. Thanks, Robert Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: On Friday 02 December 2011, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. [...] + return dmabuf; +} +EXPORT_SYMBOL(dma_buf_export); I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, because it's really a low-level function that I would expect to get used by in-kernel subsystems providing the feature to users and having back-end drivers, but it's not the kind of thing we want out-of-tree drivers to mess with. Is this really necessary? If this is intended to be a lowest-common-denominator between many drivers to allow buffer sharing, it seems like it needs to be able to be usable by all drivers. If the interface is not accessible then I fear many drivers will be forced to continue to roll their own buffer sharing mechanisms (which is exactly what we're trying to avoid here, needless to say). - Robert -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
