Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
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. You need the permission of the owners of all the dependant code that forms the work. The rules and licence are quite clear, as I think are the views of several of the rights holders on both the interpretation and intent of the licensing of their code. Please go and discuss estoppel, wilful infringement and re-licensing with your corporate attorneys. If you want to relicense components of the code then please take the matter up with the corporate attorneys of the rights holders concerned. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
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. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu October 11 2012 03:11:19 Mauro Carvalho Chehab wrote: Em Thu, 11 Oct 2012 09:22:34 +1000 Dave Airlie airl...@gmail.com escreveu: On Thu, Oct 11, 2012 at 4:17 AM, 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. I think he has that. Maybe he just needs to list them. My understanding it that he doesn't, as the dmabuf interface exposes not only the code written by this driver's author, but other parts of the Kernel. Even if someone consider just the dmabuf driver, I participated and actively contributed, together with other open source developers, during the 3 days discussions that happened at Linaro's forum where most of dmabuf design was decided, and participated, reviewed, gave suggestions approved the code, etc via email. So, even not writing the dmabuf stuff myself, I consider myself as one of the intelectual authors of the solution. Also, as dmabuf will also expose media interfaces, That's new to me. All it does is represent a buffer. It doesn't expose any interfaces, media or otherwise. my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking) BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL. The number of contributors to v4l2-ctrls.c is very limited, and I have no problem moving that to GPL. For me dmabuf is the rare exception where I prefer EXPORT_SYMBOL to prevent the worse evil of forcing vendors to create incompatible APIs. It's a sad but true that many GPU drivers are still closed source, particularly in the embedded world for which dmabuf was primarily designed. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu 11 October 2012 09:20:12 Hans Verkuil wrote: On Thu October 11 2012 03:11:19 Mauro Carvalho Chehab wrote: Em Thu, 11 Oct 2012 09:22:34 +1000 Dave Airlie airl...@gmail.com escreveu: On Thu, Oct 11, 2012 at 4:17 AM, 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. I think he has that. Maybe he just needs to list them. My understanding it that he doesn't, as the dmabuf interface exposes not only the code written by this driver's author, but other parts of the Kernel. Even if someone consider just the dmabuf driver, I participated and actively contributed, together with other open source developers, during the 3 days discussions that happened at Linaro's forum where most of dmabuf design was decided, and participated, reviewed, gave suggestions approved the code, etc via email. So, even not writing the dmabuf stuff myself, I consider myself as one of the intelectual authors of the solution. Also, as dmabuf will also expose media interfaces, That's new to me. All it does is represent a buffer. It doesn't expose any interfaces, media or otherwise. my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking) BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL. The number of contributors to v4l2-ctrls.c is very limited, and I have no problem moving that to GPL. For me dmabuf is the rare exception where I prefer EXPORT_SYMBOL to prevent the worse evil of forcing vendors to create incompatible APIs. It's a sad but true that many GPU drivers are still closed source, particularly in the embedded world for which dmabuf was primarily designed. One thing I am also worried about is that if vendors can't use dmabuf for their closed-source GPU driver, then they may not bother making GPL V4L drivers and instead stick to a proprietary solution (e.g. OpenMAX), Which would be a shame since we are making good progress with convincing vendors (esp. SoC vendors) to create GPL V4L2 drivers for their hardware. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Op 11-10-12 09:51, Hans Verkuil schreef: my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking) BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL. The number of contributors to v4l2-ctrls.c is very limited, and I have no problem moving that to GPL. For me dmabuf is the rare exception where I prefer EXPORT_SYMBOL to prevent the worse evil of forcing vendors to create incompatible APIs. It's a sad but true that many GPU drivers are still closed source, particularly in the embedded world for which dmabuf was primarily designed. One thing I am also worried about is that if vendors can't use dmabuf for their closed-source GPU driver, then they may not bother making GPL V4L drivers and instead stick to a proprietary solution (e.g. OpenMAX), Which would be a shame since we are making good progress with convincing vendors (esp. SoC vendors) to create GPL V4L2 drivers for their hardware. Powervr is probably the most well known and I knwo of at least one BSD/GPL driver, iirc tegra does similar so it should be possible to do similar for their x86 counterparts. They can still do whatever they want in userspace and are not required to disclose source for their super secret opengl/cuda/vdpau sauce, cf COPYING. Usual disclaimer applies, I'm not a lawyer, and speaking for myself here. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. Though that does beg the question why you care about this patch :-) Because my legal advice is to object and remind people who suggest otherwise. There are specific reasons to do so around estoppel and willful infringement. It's not a case of objections anyway - if the _GPL matters then it's a licensing change so you need the approval of everyone whose code is involved. At that point I think Nvidia are starting in the wrong place and need to start with a collection of vendors corporate legal contacts and then work down the call tree involved. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu 11 October 2012 13:34:07 Alan Cox wrote: 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. Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and calling into it anyway can't they. Your argument makes no rational sense of any kind. Out of curiosity: why do we have both an EXPORT_SYMBOL and an EXPORT_SYMBOL_GPL if there is no legal difference? And if there is a difference between the two, then what is it? Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu 11 October 2012 13:36:45 Hans Verkuil wrote: On Thu 11 October 2012 13:34:07 Alan Cox wrote: 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. Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and calling into it anyway can't they. Your argument makes no rational sense of any kind. Out of curiosity: why do we have both an EXPORT_SYMBOL and an EXPORT_SYMBOL_GPL if there is no legal difference? And if there is a difference between the two, then what is it? Answering myself: http://lwn.net/Articles/154602/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Hi Hans, On Thursday 11 October 2012 13:36:45 Hans Verkuil wrote: On Thu 11 October 2012 13:34:07 Alan Cox wrote: 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. Then they can accept the risk of ignoring EXPORT_SYMBOL_GPL and calling into it anyway can't they. Your argument makes no rational sense of any kind. Out of curiosity: why do we have both an EXPORT_SYMBOL and an EXPORT_SYMBOL_GPL if there is no legal difference? And if there is a difference between the two, then what is it? As far as I understand, EXPORT_SYMBOL_GPL means I consider closed-source kernel modules as a GPL violation, you can have a different opinion, but then don't use my APIs. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Em Thu, 11 Oct 2012 09:20:12 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking) If you read the Kernel COPYING file, it is explicitly said there that the Kernel is licensing with GPLv2. The _ONLY_ exception there is the allowance to use the kernel via normal syscalls: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. The usage of EXPORT_SYMBOL() is not covered there, so those symbols are also covered by GPLv2. As the usage of a kernel symbol by a proprietary driver is not explicitly listed there as a GPLv2 exception, the only concrete results of this patch is to spread FUD, as EXPORT_SYMBOL might generate some doubts on people that don't read the Kernel's COPYING file. With or without this patch, anyone with intelectual rights in the Kernel may go to court to warrant their rights against the infringing closed source drivers. By not making it explicitly, you're only trying to fool people that using it might be allowed. BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL. Agreed. The number of contributors to v4l2-ctrls.c is very limited, and I have no problem moving that to GPL. For me dmabuf is the rare exception where I prefer EXPORT_SYMBOL to prevent the worse evil of forcing vendors to create incompatible APIs. It's a sad but true that many GPU drivers are still closed source, particularly in the embedded world for which dmabuf was primarily designed. My understanding is that even the creation of incompatible Kernel API is a presumed GPL violation, as it is an attempt to circumvent the license. Basically, if vendors want to work with closed source, there are other options in the market. But if they want to work with Linux, they should be contributing upstream, instead of doing proprietary blobs. Regards, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 11 Oct 2012 09:20:12 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking) If you read the Kernel COPYING file, it is explicitly said there that the Kernel is licensing with GPLv2. The _ONLY_ exception there is the allowance to use the kernel via normal syscalls: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. The usage of EXPORT_SYMBOL() is not covered there, so those symbols are also covered by GPLv2. As the usage of a kernel symbol by a proprietary driver is not explicitly listed there as a GPLv2 exception, the only concrete results of this patch is to spread FUD, as EXPORT_SYMBOL might generate some doubts on people that don't read the Kernel's COPYING file. With or without this patch, anyone with intelectual rights in the Kernel may go to court to warrant their rights against the infringing closed source drivers. By not making it explicitly, you're only trying to fool people that using it might be allowed. Maybe a dumb question (I'm a programmer, not a lawyer), but does it change anything if we make the APIs related to *exporting* a dmabuf as EXPORT_SYMBOL() and keep the APIs related to *importing* as EXPORT_SYMBOL_GPL(). This at least avoids the non-GPL kernel module from calling in to other driver code, while still allowing the non-GPL driver to export a buffer that GPL drivers could use. BR, -R BTW, we should consider changing the control framework API to EXPORT_SYMBOL_GPL. Agreed. The number of contributors to v4l2-ctrls.c is very limited, and I have no problem moving that to GPL. For me dmabuf is the rare exception where I prefer EXPORT_SYMBOL to prevent the worse evil of forcing vendors to create incompatible APIs. It's a sad but true that many GPU drivers are still closed source, particularly in the embedded world for which dmabuf was primarily designed. My understanding is that even the creation of incompatible Kernel API is a presumed GPL violation, as it is an attempt to circumvent the license. Basically, if vendors want to work with closed source, there are other options in the market. But if they want to work with Linux, they should be contributing upstream, instead of doing proprietary blobs. 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Em Thu, 11 Oct 2012 08:47:15 -0500 Rob Clark robdcl...@gmail.com escreveu: On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em Thu, 11 Oct 2012 09:20:12 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. As long as dmabuf uses EXPORT_SYMBOL_GPL that is definitely correct. Does your statement also hold if dmabuf would use EXPORT_SYMBOL? (Just asking) If you read the Kernel COPYING file, it is explicitly said there that the Kernel is licensing with GPLv2. The _ONLY_ exception there is the allowance to use the kernel via normal syscalls: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. The usage of EXPORT_SYMBOL() is not covered there, so those symbols are also covered by GPLv2. As the usage of a kernel symbol by a proprietary driver is not explicitly listed there as a GPLv2 exception, the only concrete results of this patch is to spread FUD, as EXPORT_SYMBOL might generate some doubts on people that don't read the Kernel's COPYING file. With or without this patch, anyone with intelectual rights in the Kernel may go to court to warrant their rights against the infringing closed source drivers. By not making it explicitly, you're only trying to fool people that using it might be allowed. Maybe a dumb question (I'm a programmer, not a lawyer), but does it change anything if we make the APIs related to *exporting* a dmabuf as EXPORT_SYMBOL() and keep the APIs related to *importing* as EXPORT_SYMBOL_GPL(). This at least avoids the non-GPL kernel module from calling in to other driver code, while still allowing the non-GPL driver to export a buffer that GPL drivers could use. IANAL. My understanding is that nothing changes by using either programmer's dialect: it sounds doubtful that the court would actually take a look into the Kernel's source code: they're lawyers, not programmers, and both clauses are just Kernel's source code. Nothing more, nothing less: EXPORT_SYMBOL, is not EXPORT_SYMBOL_BSD (or similar): this syntax doesn't bring _any_kind_ of additional licensing rights. That means that the licensing terms that apply there are just the ones stated at COPYING file. So, in any case, the court will judge the allegations based at the Kernel licensing terms, and will seek if the terms of such licensing were violated. The court will also likely use formal notifications of potential infringements, like the ones in this thread, and other non-technical documents, like meeting reports, email threads, etc, in order to check who has intelectual rights on the Linux Kernel, and if the ones that violated the rights did it by purpose. Regards, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
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. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Em Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell rmor...@nvidia.com escreveu: 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 NAK, as already explained at: http://lists.freedesktop.org/archives/dri-devel/2012-January/018281.html Regards, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 4:17 AM, 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. I think he has that. Maybe he just needs to list them. But this doesn't change the license on the code at all really, so its actually not like a re-license where you need approval. But in any case I personally don't care about this interface being used if the alternative is they do it themselves. I'm still not going to debug things with a binary module taint. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 4:17 AM, 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. I think he has that. Maybe he just needs to list them. My understanding it that he doesn't, as the dmabuf interface exposes not only the code written by this driver's author, but other parts of the Kernel. Even if someone consider just the dmabuf driver, I participated and actively contributed, together with other open source developers, during the 3 days discussions that happened at Linaro's forum where most of dmabuf design was decided, and participated, reviewed, gave suggestions approved the code, etc via email. So, even not writing the dmabuf stuff myself, I consider myself as one of the intelectual authors of the solution. Also, as dmabuf will also expose media interfaces, my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. Though that does beg the question why you care about this patch :-) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Em Thu, 11 Oct 2012 09:22:34 +1000 Dave Airlie airl...@gmail.com escreveu: On Thu, Oct 11, 2012 at 4:17 AM, 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. I think he has that. Maybe he just needs to list them. My understanding it that he doesn't, as the dmabuf interface exposes not only the code written by this driver's author, but other parts of the Kernel. Even if someone consider just the dmabuf driver, I participated and actively contributed, together with other open source developers, during the 3 days discussions that happened at Linaro's forum where most of dmabuf design was decided, and participated, reviewed, gave suggestions approved the code, etc via email. So, even not writing the dmabuf stuff myself, I consider myself as one of the intelectual authors of the solution. Also, as dmabuf will also expose media interfaces, my understaning is that the drivers/media/ authors should also ack with this licensing (possible) change. I am one of the main contributors there. Alan also has copyrights there, and at other parts of the Linux Kernel, including the driver's core, from where all Linux Kernel drivers are derivative work, including this one. As Alan well said, many other core Linux Kernel authors very likely share this point of view. So, developers implicitly or explicitly copied in this thread that might be considering the usage of dmabuf on proprietary drivers should consider this email as a formal notification of my viewpoint: e. g. that I consider any attempt of using DMABUF or media core/drivers together with proprietary Kernelspace code as a possible GPL infringement. Regards, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Tue, Jan 17, 2012 at 6:08 PM, 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. We discussed this topic at the kernel-gfx mini-summit at ELC. Following the discussion, I agree that dma-buf infrastructure is intended as an interface between driver subsystems. And because (for now) all the other arm SoC gl(es) stacks unfortunately involve a closed src userspace, and since I consider userspace and kernel as tightly coupled in the realm of graphics stacks, I don't think we can really claim the moral high-ground here. So I can't object to use of EXPORT_SYMBOL() instead of EXPORT_SYMBOL_GPL(). That said, I expect the dma-buf infrastructure to still be evolving and it is the responsibility for out-of-tree users of the API (GPL or otherwise) to adapt as the dma-buf API changes. And there isn't much the in-tree drivers can do when it comes to debugging of buffer sharing issues with out-of-tree drivers (binary or otherwise), leaving the debugging responsibility to the owners of different out-of-tree drivers. BR, -R Signed-off-by: Robert Morell rmor...@nvidia.com --- drivers/base/dma-buf.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index e38ad24..4ed5a5d 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -101,7 +101,7 @@ struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops, return dmabuf; } -EXPORT_SYMBOL_GPL(dma_buf_export); +EXPORT_SYMBOL(dma_buf_export); /** @@ -126,7 +126,7 @@ int dma_buf_fd(struct dma_buf *dmabuf) 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 @@ -152,7 +152,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 @@ -167,7 +167,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, @@ -213,7 +213,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; @@ -235,7 +235,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; @@ -265,7 +265,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 @@ -288,4 +288,4 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, mutex_unlock(attach-dmabuf-lock); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed symbols can be used by the binary blobs, possibly with an open-sourced shim which provides the buffer-sharing interface to the binary blobs? Are there any reasons to not consider this approach? The GPL requires all the code of a work is source. All of it, no shims no magic glue. EXPORT_SYMBOL isn't an indication you can use it for binary modules. The GPL licence is quite clear on what is covered. Since you've asked this I'm advised by my lawyer to respond to all such assumptions of legality of binary modules... For a Linux kernel containing any code I own the code is under the GNU public license v2 (in some cases or later), I have never given permission for that code to be used as part of a combined or derivative work which contains binary chunks. I have never said that modules are somehow magically outside the GPL and I am doubtful that in most cases a work containing binary modules for a Linux kernel is compatible with the licensing, although I accept there may be some cases that it is. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Em 25-01-2012 10:30, Alan Cox escreveu: Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed symbols can be used by the binary blobs, possibly with an open-sourced shim which provides the buffer-sharing interface to the binary blobs? Are there any reasons to not consider this approach? The GPL requires all the code of a work is source. All of it, no shims no magic glue. EXPORT_SYMBOL isn't an indication you can use it for binary modules. The GPL licence is quite clear on what is covered. Agreed. Such patch won't change anything. The discussions, patch reviews, etc were under the assumption that the code will be GPL'd, plus the subsystems that are exposed by this interface also assumes that. Any trials to circumvent it seem to violate Kernel owner's rights. Since you've asked this I'm advised by my lawyer to respond to all such assumptions of legality of binary modules... For a Linux kernel containing any code I own the code is under the GNU public license v2 (in some cases or later), I have never given permission for that code to be used as part of a combined or derivative work which contains binary chunks. I have never said that modules are somehow magically outside the GPL and I am doubtful that in most cases a work containing binary modules for a Linux kernel is compatible with the licensing, although I accept there may be some cases that it is. Alan I second Alan: For a Linux kernel containing any code I own the code is under the GNU public license v2 (in a few cases, where explicitly said GPLv2 or later or dual GNU/BSD), I have never given permission for that code to be used as part of a combined or derivative work which contains binary chunks. Regards, Mauro. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu: Em 25-01-2012 10:30, Alan Cox escreveu: Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed symbols can be used by the binary blobs, possibly with an open-sourced shim which provides the buffer-sharing interface to the binary blobs? Are there any reasons to not consider this approach? The GPL requires all the code of a work is source. All of it, no shims no magic glue. EXPORT_SYMBOL isn't an indication you can use it for binary modules. The GPL licence is quite clear on what is covered. Agreed. Such patch won't change anything. The discussions, patch reviews, etc were under the assumption that the code will be GPL'd, plus the subsystems that are exposed by this interface also assumes that. Any trials to circumvent it seem to violate Kernel owner's rights. In time, let me rephrase it: Any trial to circumvent it seems to be an attempt to violate Kernel owner's rights. Since you've asked this I'm advised by my lawyer to respond to all such assumptions of legality of binary modules... For a Linux kernel containing any code I own the code is under the GNU public license v2 (in some cases or later), I have never given permission for that code to be used as part of a combined or derivative work which contains binary chunks. I have never said that modules are somehow magically outside the GPL and I am doubtful that in most cases a work containing binary modules for a Linux kernel is compatible with the licensing, although I accept there may be some cases that it is. Alan I second Alan: For a Linux kernel containing any code I own the code is under the GNU public license v2 (in a few cases, where explicitly said GPLv2 or later or dual GNU/BSD), I have never given permission for that code to be used as part of a combined or derivative work which contains binary chunks. Regards, Mauro. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote: On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: On Wed, Jan 18, 2012 at 5:38 AM, 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. + 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. This discussion seems to have stagnated; how do we move forward here? Sumit, as the primary author and new maintainer (congrats!) of the dma-buf infrastructure, it seems like it's really your call how to proceed. I'd still like to see this be something that we can use from the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have argued in this thread. It really seems to me that this change on a technical level won't have any adverse effect on the scenarios where it can be used today, but it will allow it to be used more widely, which will prevent duplication and fragmentation in the future and be greatly appreciated by users of hardware such as Optimus. Given that I've participated quite a bit in the design of dma_buf as-is, let me throw in my totally irrelevant opinion, too ;-) I'll refrain from comment on the actual patch, it's obviously a hot topic. Furthermore I might need to ask Intel's legal dep for guidance to asses things wrt my own contributions to dma_buf. Otoh I'd like nvidia to be on board, especially when we're desingned additions to dma_buf required to make it really work for multiple gpus. In additions it looks like that the nvidia blob will only be an importer of a dma_buf, at least for the use-cases discussed here. So why don't you just ditch this patch here and add a small shim to your blob to interface with drm's prime as an importing driver? I personally would deem that acceptable and I think Dave wouldn't mind too much, either. Hi Everyone! (Apologies for delay in replying; was OoO for past couple of days) Thanks very much for this discussion - a couple of things: 1. I am definitely willing to make changes as needed to get as many devices / subsystems / frameworks to use the dma-buf infrastructure. This could include changing the way symbols are exported, if that is the *only* way to get things done. 2. With that premise, I quite like the idea that Daniel gave (of course, in his capacity as one of the top contributors behind dma-buf infrastructure, and like he said, not as an Intel employee) - so let me ask the following: Robert, Dave, Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed symbols can be used by the binary blobs, possibly with an open-sourced shim which provides the buffer-sharing interface to the binary blobs? Are there any reasons to not consider this approach? Also, if some of you are going to be at ELC mid-Feb at SFO, we could meet up face-to-face and thrash out possible ways forward. Yours, Daniel Thanks, and best regards, ~Sumit. Disclaimer: This is my own opinion and I do not speak as an Intel employee here. -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: On Wed, Jan 18, 2012 at 5:38 AM, 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. + 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. This discussion seems to have stagnated; how do we move forward here? Sumit, as the primary author and new maintainer (congrats!) of the dma-buf infrastructure, it seems like it's really your call how to proceed. I'd still like to see this be something that we can use from the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have argued in this thread. It really seems to me that this change on a technical level won't have any adverse effect on the scenarios where it can be used today, but it will allow it to be used more widely, which will prevent duplication and fragmentation in the future and be greatly appreciated by users of hardware such as Optimus. Let me know if you have any questions. Thanks, Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote: On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: On Wed, Jan 18, 2012 at 5:38 AM, 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. + 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. This discussion seems to have stagnated; how do we move forward here? Sumit, as the primary author and new maintainer (congrats!) of the dma-buf infrastructure, it seems like it's really your call how to proceed. I'd still like to see this be something that we can use from the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have argued in this thread. It really seems to me that this change on a technical level won't have any adverse effect on the scenarios where it can be used today, but it will allow it to be used more widely, which will prevent duplication and fragmentation in the future and be greatly appreciated by users of hardware such as Optimus. Given that I've participated quite a bit in the design of dma_buf as-is, let me throw in my totally irrelevant opinion, too ;-) I'll refrain from comment on the actual patch, it's obviously a hot topic. Furthermore I might need to ask Intel's legal dep for guidance to asses things wrt my own contributions to dma_buf. Otoh I'd like nvidia to be on board, especially when we're desingned additions to dma_buf required to make it really work for multiple gpus. In additions it looks like that the nvidia blob will only be an importer of a dma_buf, at least for the use-cases discussed here. So why don't you just ditch this patch here and add a small shim to your blob to interface with drm's prime as an importing driver? I personally would deem that acceptable and I think Dave wouldn't mind too much, either. Yours, Daniel Disclaimer: This is my own opinion and I do not speak as an Intel employee here. -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote: On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: On Wed, Jan 18, 2012 at 5:38 AM, 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. + Konrad, Arnd, Mauro: there were strong objections on using EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I I am going to defer to what David Airlie recommends. suggest we first arrive at a consensus before merging this patch. This discussion seems to have stagnated; how do we move forward here? Sumit, as the primary author and new maintainer (congrats!) of the dma-buf infrastructure, it seems like it's really your call how to proceed. I'd still like to see this be something that we can use from the nvidia and fglrx drivers for Xorg buffer sharing, as I and Dave have argued in this thread. It really seems to me that this change on a technical level won't have any adverse effect on the scenarios where it can be used today, but it will allow it to be used more widely, which will prevent duplication and fragmentation in the future and be greatly appreciated by users of hardware such as Optimus. Let me know if you have any questions. Thanks, Robert ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 5:38 AM, 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. + 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. Best regards, ~Sumit. snip ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 12:14 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 18 January 2012, Semwal, Sumit wrote: On Wed, Jan 18, 2012 at 5:38 AM, 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. + 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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 1:55 PM, Ilija Hadzic ihad...@research.bell-labs.com wrote: On Wed, 18 Jan 2012, Dave Airlie wrote: 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. Please correct me if I blab a nonsense here, but just the other day, we have seen a different thread in which it was decided that user cannot turn on buffer sharing at compile time explicitly, but rather a driver that needs it would turn it on automatically. Doesn't that alone exclude out-of-tree drivers? In other words if you have two out-of-tree drivers that want to use DMA buffer sharing, and no other enabled driver in the kernel enables it implicitly, then such a kernel won't make it possible for said two drivers to work. Well the use case at least on x86 would be open x86 driver sharing with closed nvidia driver, if two closed drivers wanted to share I'd except them to do it internally anyways. Frankly, I never understood this low-level interface argument that is kicked around when EXPORT_SYMBOL_GPL topic is brought up. My view to EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL is that it really boils down to license controversy about binary/proprietary modules in Linux kernel. To me it's about whether the authors of certain code (for mostly phylosophical reasons) agree that their (GPL) code is OK or not OK to link against non-GPL module. From that angle, I am not sure if it is ethical at all to modify how the symbol is exported without explicit consent of the original author (regardless of what we think about GPL/proprietary modules covtroversy). So if NVidia needs to link DMA buffer sharing against their proprietary driver, they should have explicit permission from the original author to turn its symbols into EXPORT_SYMBOL. Which is the point of their patch, to ask permission from the author. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
Em 18-01-2012 10:14, Arnd Bergmann escreveu: On Wednesday 18 January 2012, Semwal, Sumit wrote: On Wed, Jan 18, 2012 at 5:38 AM, 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. + 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. NAK I fully agree with Arnd. A bug on a driver using such low-level interface could cause side effects at the wrong places. In order to handle such bugs, the developers and the maintainers of both subsystems need to see the source code of the entire pipeline, with is not possible if is there any non-GPL'd driver. NAK Mauro. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 12:23 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 18-01-2012 10:14, Arnd Bergmann escreveu: On Wednesday 18 January 2012, Semwal, Sumit wrote: On Wed, Jan 18, 2012 at 5:38 AM, 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. + 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. NAK I fully agree with Arnd. A bug on a driver using such low-level interface could cause side effects at the wrong places. In order to handle such bugs, the developers and the maintainers of both subsystems need to see the source code of the entire pipeline, with is not possible if is there any non-GPL'd driver. Just as an aside you shouldn't be debugging tainted kernels anyways. The thing is if we don't provide the interface that is known working for this, then we end up requiring the nvidia binary to jump through hoops which is more likely to make thing unstable. At that point I'd start to seriously consider whether drm needs dma-buf since one of the things I will get pressure to share buffers with is for optimus. The pressure isn't from nvidia, but from users and customers. I'd like to at least remove debuggabilty from the argument, that is why we have tainting, if you ignore taint + lsmod output then export_symbol won't matter. Dave. NAK Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
