[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
> Unlikely as most of the code I've written belongs to Intel or Red Hat. I > also have better things to do with life than sue Nvidia and start an all > out copyright and patent war in Linuxspace. I forgot to ask, but after your petty G+ trolling, if most of the code belings to Intel or Red Hat, why do we need to listen to *your* lawyers advice? It seems like you aren't a major rights holder but a troll. Dave.
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
Unlikely as most of the code I've written belongs to Intel or Red Hat. I also have better things to do with life than sue Nvidia and start an all out copyright and patent war in Linuxspace. I forgot to ask, but after your petty G+ trolling, if most of the code belings to Intel or Red Hat, why do we need to listen to *your* lawyers advice? It seems like you aren't a major rights holder but a troll. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
> From the fact this patch keeps getting resubmitted despite repeated > objection I deduce they are in fact of the view it does matter and that > therefore it is a licensing change and they are scared of the > consequences of ignoring it. > No I think they just want to have to write a pointless hack lie in their kernel module. There is no nice way for nvidia developers to say our lawyers don't think this is a license issues without doing MODULE_LICENSE("GPL\0 OH NOT WE DIDNT OUR LAWYESR ARE OKAY"); I don't think I'd be going quite into how illegal it is. The thing is I can't base a useful userspace interface on this, and since the nvidia driver exists everwhere despite what we'd wish, I'd rather let the users have some hope of a sane architecture, instead of nvidia having to replace even more userspace code and kernel code with their own insane shit. Dave.
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox wrote: >> > 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 please stick with the facts. This isn't a relicense of anything. > > In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer > - NO. Does my laywer disagree with you - YES. Okay then we should remove this code from the kernel forthwith, as I showed it was illegally relicensed previously in your lawyers opinion. Dave.
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
b>> >> Alan please stick with the facts. This isn't a relicense of anything. >> EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a >> totally pointless thing, it should be >> EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it >> really should be EXPORT_SYMBOL, and really consult your lawyers >> anyways. >> > > Also we should look at this > http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html > > original code posting had no EXPORT_SYMBOL, so the original author's > intents were quite clear. Yeah so a history research shows this didn't change until v3 of the code base, and I don't think any lawyers were consulted about changing the exports then, so I don't see why we should need any now. If we do need some now, then we needed some then thus making the original change of the exports a problem. Now how do I withdraw a Signed-off-by and have dma-buf removed from the kernel? (not I'm just spouting bullshit here which has as much value as Alan's, as I said before unless someone grows a pair and sues someone its all just IANAL and humble opinions.) Dave.
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
>> 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 please stick with the facts. This isn't a relicense of anything. > EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a > totally pointless thing, it should be > EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it > really should be EXPORT_SYMBOL, and really consult your lawyers > anyways. > Also we should look at this http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html original code posting had no EXPORT_SYMBOL, so the original author's intents were quite clear. Dave.
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 17, 2012 at 7:53 PM, Alan Cox wrote: >> 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 please stick with the facts. This isn't a relicense of anything. EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a totally pointless thing, it should be EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it really should be EXPORT_SYMBOL, and really consult your lawyers anyways. Dave.
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, 17 Oct 2012 20:22:04 +1000 Dave Airlie wrote: > On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox wrote: > >> > 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 please stick with the facts. This isn't a relicense of anything. > > > > In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer > > - NO. Does my laywer disagree with you - YES. > > Okay then we should remove this code from the kernel forthwith, as I > showed it was illegally relicensed previously in your lawyers opinion. That would not be the same question I asked my lawyer. Anyway I refer you to the Developer's Certificate of Origin 1.1. Anything Signed off was submitted under the GPL and so is usable as part of a GPL derived work, but not as part of a non GPL derived work. Thus Nouveau can happily use it for example. Simples. And as I said before if Nvidia believe the _GPL makes no difference and their work is not derivative then it's clearly within their power to just ignore it, at which point *they* take the risk on their own.
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
> > 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 please stick with the facts. This isn't a relicense of anything. In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer - NO. Does my laywer disagree with you - YES. > EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a > totally pointless thing, In your personal viewpoint. I disagree. I'm a rights holder too. Several rights holders have made it clear the change is not wanted. It's over, done, buried. If you want it can go as far as Linus and then he can get a copy of all the discussion and say that same as he did in the classic video. Should I start submitting all the Intel non-free user space X drivers at this point as there seems to be a dramatic policy change going on here ? Alan
[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
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: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 17, 2012 at 7:53 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: 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 please stick with the facts. This isn't a relicense of anything. EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a totally pointless thing, it should be EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it really should be EXPORT_SYMBOL, and really consult your lawyers anyways. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
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 please stick with the facts. This isn't a relicense of anything. EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a totally pointless thing, it should be EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it really should be EXPORT_SYMBOL, and really consult your lawyers anyways. Also we should look at this http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html original code posting had no EXPORT_SYMBOL, so the original author's intents were quite clear. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
b Alan please stick with the facts. This isn't a relicense of anything. EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a totally pointless thing, it should be EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it really should be EXPORT_SYMBOL, and really consult your lawyers anyways. Also we should look at this http://lists.linaro.org/pipermail/linaro-mm-sig/2011-September/000616.html original code posting had no EXPORT_SYMBOL, so the original author's intents were quite clear. Yeah so a history research shows this didn't change until v3 of the code base, and I don't think any lawyers were consulted about changing the exports then, so I don't see why we should need any now. If we do need some now, then we needed some then thus making the original change of the exports a problem. Now how do I withdraw a Signed-off-by and have dma-buf removed from the kernel? (not I'm just spouting bullshit here which has as much value as Alan's, as I said before unless someone grows a pair and sues someone its all just IANAL and humble opinions.) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
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 please stick with the facts. This isn't a relicense of anything. In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer - NO. Does my laywer disagree with you - YES. EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a totally pointless thing, In your personal viewpoint. I disagree. I'm a rights holder too. Several rights holders have made it clear the change is not wanted. It's over, done, buried. If you want it can go as far as Linus and then he can get a copy of all the discussion and say that same as he did in the classic video. Should I start submitting all the Intel non-free user space X drivers at this point as there seems to be a dramatic policy change going on here ? Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: 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 please stick with the facts. This isn't a relicense of anything. In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer - NO. Does my laywer disagree with you - YES. Okay then we should remove this code from the kernel forthwith, as I showed it was illegally relicensed previously in your lawyers opinion. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, 17 Oct 2012 20:22:04 +1000 Dave Airlie airl...@gmail.com wrote: On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: 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 please stick with the facts. This isn't a relicense of anything. In your opinion. Are you a qualified IP attorney - NO. Are you my lawyer - NO. Does my laywer disagree with you - YES. Okay then we should remove this code from the kernel forthwith, as I showed it was illegally relicensed previously in your lawyers opinion. That would not be the same question I asked my lawyer. Anyway I refer you to the Developer's Certificate of Origin 1.1. Anything Signed off was submitted under the GPL and so is usable as part of a GPL derived work, but not as part of a non GPL derived work. Thus Nouveau can happily use it for example. Simples. And as I said before if Nvidia believe the _GPL makes no difference and their work is not derivative then it's clearly within their power to just ignore it, at which point *they* take the risk on their own. From the fact this patch keeps getting resubmitted despite repeated objection I deduce they are in fact of the view it does matter and that therefore it is a licensing change and they are scared of the consequences of ignoring it. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
From the fact this patch keeps getting resubmitted despite repeated objection I deduce they are in fact of the view it does matter and that therefore it is a licensing change and they are scared of the consequences of ignoring it. No I think they just want to have to write a pointless hack lie in their kernel module. There is no nice way for nvidia developers to say our lawyers don't think this is a license issues without doing MODULE_LICENSE(GPL\0 OH NOT WE DIDNT OUR LAWYESR ARE OKAY); I don't think I'd be going quite into how illegal it is. The thing is I can't base a useful userspace interface on this, and since the nvidia driver exists everwhere despite what we'd wish, I'd rather let the users have some hope of a sane architecture, instead of nvidia having to replace even more userspace code and kernel code with their own insane shit. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 > > wrote: > > > On Wed, 10 Oct 2012 08:56:32 -0700 > > > Robert Morell 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
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
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
> > 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. > > But then why object to the change, your objection makes sense, naking > the patch makes none, if you believe in your objection. [l/k added as I imagine a few other peopel will want to see this who don't read driver specific lists, Greg especially I guess] 'estoppel' and because my legal advice is specifically to do so. If you don't understand why it matters then please get qualified legal advice. I'm also objecting to the failure to follow proper process. If this does make a difference as Nvidia seem to think then it is a clear requirement that you gain permission from every rightsholder affected, as with any other licensing change. So I would suggest Nvidia start by going through the call tree and all potential rightsholders and negotiating with all their corporate attorneys to get each of them to provide a Signed-off-by: line for that change and perhaps charge them for a license in the process. Now as it happens lots of other people have objected to this last time it was posted, and this time, so maybe they should just recognize the clear will of the rightsholders concerned and give up on it. It's very clear how most rights holders involved see the Nvidia situation. What was it Linus said.. http://www.youtube.com/watch?v=IVpOyKCNZYw so right from the top the opinion seems to be fairly clear. > Also really its just bullshit handwaving all of it, your objection, > _GPL etc. until someone grows a pair and sues someone, instead of > hiding behind their employment status. If you really believed you were > right, you could retire on the settlement payout. Unlikely as most of the code I've written belongs to Intel or Red Hat. I also have better things to do with life than sue Nvidia and start an all out copyright and patent war in Linuxspace. It's simple enough If Nvidia think their code is not derivative then why do they care about the _GPL being significant ? Nouveau can call the DMA buf methods. Alan
[Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 9:34 PM, 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. But then why object to the change, your objection makes sense, naking the patch makes none, if you believe in your objection. Also really its just bullshit handwaving all of it, your objection, _GPL etc. until someone grows a pair and sues someone, instead of hiding behind their employment status. If you really believed you were right, you could retire on the settlement payout. Dave.
Re: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
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. But then why object to the change, your objection makes sense, naking the patch makes none, if you believe in your objection. [l/k added as I imagine a few other peopel will want to see this who don't read driver specific lists, Greg especially I guess] 'estoppel' and because my legal advice is specifically to do so. If you don't understand why it matters then please get qualified legal advice. I'm also objecting to the failure to follow proper process. If this does make a difference as Nvidia seem to think then it is a clear requirement that you gain permission from every rightsholder affected, as with any other licensing change. So I would suggest Nvidia start by going through the call tree and all potential rightsholders and negotiating with all their corporate attorneys to get each of them to provide a Signed-off-by: line for that change and perhaps charge them for a license in the process. Now as it happens lots of other people have objected to this last time it was posted, and this time, so maybe they should just recognize the clear will of the rightsholders concerned and give up on it. It's very clear how most rights holders involved see the Nvidia situation. What was it Linus said.. http://www.youtube.com/watch?v=IVpOyKCNZYw so right from the top the opinion seems to be fairly clear. Also really its just bullshit handwaving all of it, your objection, _GPL etc. until someone grows a pair and sues someone, instead of hiding behind their employment status. If you really believed you were right, you could retire on the settlement payout. Unlikely as most of the code I've written belongs to Intel or Red Hat. I also have better things to do with life than sue Nvidia and start an all out copyright and patent war in Linuxspace. It's simple enough If Nvidia think their code is not derivative then why do they care about the _GPL being significant ? Nouveau can call the DMA buf methods. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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
[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/
[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
[PATCH] dma-buf: Use EXPORT_SYMBOL
>> On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox >> wrote: >> > On Wed, 10 Oct 2012 08:56:32 -0700 >> > Robert Morell 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.
[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
[PATCH] dma-buf: Use EXPORT_SYMBOL
> 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. Alan
[PATCH] dma-buf: Use EXPORT_SYMBOL
> 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) Yes. The GPL talks about derivative works (as does copyright law). Alan
[PATCH] dma-buf: Use EXPORT_SYMBOL
Em Thu, 11 Oct 2012 08:47:15 -0500 Rob Clark escreveu: > On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab > wrote: > > Em Thu, 11 Oct 2012 09:20:12 +0200 > > Hans Verkuil 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
[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
[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 escreveu: > > > > > On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox > > > wrote: > > > > On Wed, 10 Oct 2012 08:56:32 -0700 > > > > Robert Morell 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
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox wrote: > On Wed, 10 Oct 2012 08:56:32 -0700 > Robert Morell 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.
[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 escreveu: > > > On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox > > wrote: > > > On Wed, 10 Oct 2012 08:56:32 -0700 > > > Robert Morell 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
[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 wrote: > > On Wed, 10 Oct 2012 08:56:32 -0700 > > Robert Morell 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
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 6:13 AM, Mauro Carvalho Chehab wrote: > Em Thu, 11 Oct 2012 09:20:12 +0200 > Hans Verkuil 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 majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf: Use EXPORT_SYMBOL
Em Thu, 11 Oct 2012 09:20:12 +0200 Hans Verkuil 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
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: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
On Thu, Oct 11, 2012 at 9:34 PM, Alan Cox a...@lxorguk.ukuu.org.uk 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. But then why object to the change, your objection makes sense, naking the patch makes none, if you believe in your objection. Also really its just bullshit handwaving all of it, your objection, _GPL etc. until someone grows a pair and sues someone, instead of hiding behind their employment status. If you really believed you were right, you could retire on the settlement payout. 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 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
[PATCH] dma-buf: Use EXPORT_SYMBOL
Em Thu, 11 Oct 2012 09:22:34 +1000 Dave Airlie escreveu: > On Thu, Oct 11, 2012 at 4:17 AM, Alan Cox wrote: > > On Wed, 10 Oct 2012 08:56:32 -0700 > > Robert Morell 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
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell 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
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Oct 10, 2012 at 1:17 PM, Alan Cox wrote: > On Wed, 10 Oct 2012 08:56:32 -0700 > Robert Morell 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. BR, -R > 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 at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Use EXPORT_SYMBOL
Em Wed, 10 Oct 2012 08:56:32 -0700 Robert Morell 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 NAK, as already explained at: http://lists.freedesktop.org/archives/dri-devel/2012-January/018281.html Regards, Mauro
[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 --- 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(>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(>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 @@ void *dma_buf_vmap(struct
[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: [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
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Tue, Jan 17, 2012 at 6:08 PM, Robert Morell 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 > --- > ?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(>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(>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(>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 majordomo at vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html > Please read the FAQ at ?http://www.tux.org/lkml/
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
[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
[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.
[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.
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter 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 >> > 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: daniel at ffwll.ch > Mobile: +41 (0)79 365 57 48
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
[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 > > 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: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
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
[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 > > 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
[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 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
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
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 12:23 PM, Mauro Carvalho Chehab 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 >>> 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 majordomo at vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html > Please read the FAQ at ?http://www.tux.org/lkml/
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 06:00:54AM -0800, Dave Airlie wrote: > On Wed, Jan 18, 2012 at 1:55 PM, Ilija Hadzic > 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. Yes, this is one potential use case that I have in mind. This is digressing a bit, but the binary nvidia driver is the best way that I see that we can support our users with a feature set compatible to that available to other operating systems. For technical reasons, we've chosen to leverage a lot of common code written internally, which allows us to release support for new hardware and software features much more quickly than if those of us working on the Linux/FreeBSD/Solaris drivers wrote it all from scratch. This means that we share a lot with other NVIDIA drivers, but we for better or worse can't share much infrastructure like DRI. > > 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. Correct. Right now, that covers Optimus laptops with Intel integrated graphics and an NVIDIA GPU. We'd only use the dma-buf interface in the case of interoperating with the Intel device. I only see such hardware becoming more common. For example, in the future, if we can't agree on using EXPORT_SYMBOL, then if somebody were to introduce a laptop that had a Tegra GPU (which uses GPL-compatible open-source Linux drivers) and a GeForce GPU (which is, as described above, supported by our existing binary driver) then I imagine we'd have no choice but to re-implement a different open-source buffer allocation mechanism for Tegra that could be used between the two, or just continue using our existing nvhost code. This, along with every other SoC's version, is exactly what the dma-buf project was intended to replace. > > 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. Right. I never intended to submit this patch behind anyone's back, I just wanted to bring this to their attention and ask if the change could be made so that we could better serve shared-graphics users. Thanks, Robert
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell 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.
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wednesday 18 January 2012, Ilija Hadzic 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. > > A lot of good stuff is coming out of nvidia these days regarding for their tegra ARM socs. I wouldn't be surprised to see them in the same boat as Intel and AMD regarding their support for free drivers in the near future and I think it's worth supporting the people inside of nvidia that are fighting for that instead of the others that are against it. Having more interesting features in nouveau that are not in the proprietary driver would probably help on that front, too. > 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. The controversy is about whether a module is a derived work of the kernel when you link it in. Traditionally, some modules were not considered derived works by a lot of people arguing that we have a public module interface that acts as a barrier for the license in the same way that the syscall interface lets you run proprietary applications. The EXPORT_SYMBOL_GPL is all about symbols that are too low-level to be considered part of that public module API (assuming that this API exists). The argument is that symbols which are not meant to be used in third-party modules can never be a license barrier and anything using them is a derived work even if you consider other modules not to be a derived work of the kernel. Note that this argument can still hold for low-level symbols that are marked as EXPORT_SYMBOL, using EXPORT_SYMBOL_GPL just makes it explicit. Arnd
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 1:55 PM, Ilija Hadzic 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.
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wed, Jan 18, 2012 at 12:14 PM, Arnd Bergmann wrote: > On Wednesday 18 January 2012, Semwal, Sumit wrote: >> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell 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.
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Wednesday 18 January 2012, Semwal, Sumit wrote: > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell 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 Arnd
[PATCH] dma-buf: Use EXPORT_SYMBOL
On Tue, 17 Jan 2012 16:08:17 -0800 Robert Morell 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. > > Signed-off-by: Robert Morell Please get a Signed-off-by: from the original authors. In some eyes you are making what is a licensing change, and that needs the rights holders permissions. So this patch at the very least needs approval from TI and Linaro.
[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 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.
[PATCH] dma-buf: Use EXPORT_SYMBOL
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. On a related note, EXPORT_SYMBOL_GPL will still happily link with out-of-tree driver, for as long as that driver comes under GPL-compatible license. So it's not really a question of whether the driver is out-of-tree or in-tree, but it's a question of driver's license. 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.
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
[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 --- 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(>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(>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(>dmabuf->lock); } -EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); +EXPORT_SYMBOL(dma_buf_unmap_attachment); -- 1.7.3.4
[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 --- 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel