* [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL @ 2018-09-13 19:43 Dan Williams 2018-09-13 20:05 ` Guenter Roeck 2018-09-13 20:14 ` Greg KH 0 siblings, 2 replies; 10+ messages in thread From: Dan Williams @ 2018-09-13 19:43 UTC (permalink / raw) To: ksummit Currently the only guidance we have about EXPORT_SYMBOL_GPL usage in Documentation/ is: "It implies that the function is considered an internal implementation issue, and not really an interface." The topics for a Maintainer Summit discussion are: 1/ The criteria "is considered an internal implementation issue" is sufficiently vague and seems to lead to arbitrary and subjective decisions by individual developers. Are there some objective technical criteria we can apply? For example, the symbol consumes other EXPORT_SYMBOL_GPL functionality, the symbol can effect kernel-wide state / policy, or the symbol leaks internal implementation details that are more unstable than typical EXPORT_SYMBOL apis. Any additional subjective criteria to consider? For example, it would be better for long term health of Linux if the consumers of a given API had the EXPORT_SYMBOL_GPL-related encouragement to get their code upstream. 2/ With expanded criteria in hand the question then becomes what are the considerations for changing an existing symbol between EXPORT_SYMBOL or EXPORT_SYMBOL_GPL? I expect it would be awkward and unwanted to set down hard rules, but a list of considerations that a change proposal needs to address would at least help guide such discussions. Not being a lawyer, I'm less interested in legal concerns, and more the technical, code maintenance, and health of the kernel aspects of what EXPORT_SYMBOL_GPL influences. Note, I am not available to travel to Edinburgh to lead this discussion. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-13 19:43 [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL Dan Williams @ 2018-09-13 20:05 ` Guenter Roeck 2018-09-13 20:14 ` Greg KH 1 sibling, 0 replies; 10+ messages in thread From: Guenter Roeck @ 2018-09-13 20:05 UTC (permalink / raw) To: Dan Williams; +Cc: ksummit On Thu, Sep 13, 2018 at 12:43:15PM -0700, Dan Williams wrote: > Currently the only guidance we have about EXPORT_SYMBOL_GPL usage in > Documentation/ is: > > "It implies that the function is considered an internal implementation > issue, and not really an interface." > > The topics for a Maintainer Summit discussion are: > > 1/ The criteria "is considered an internal implementation issue" is > sufficiently vague and seems to lead to arbitrary and subjective > decisions by individual developers. Are there some objective technical > criteria we can apply? For example, the symbol consumes other > EXPORT_SYMBOL_GPL functionality, the symbol can effect kernel-wide > state / policy, or the symbol leaks internal implementation details > that are more unstable than typical EXPORT_SYMBOL apis. Any additional > subjective criteria to consider? For example, it would be better for > long term health of Linux if the consumers of a given API had the > EXPORT_SYMBOL_GPL-related encouragement to get their code upstream. > > 2/ With expanded criteria in hand the question then becomes what are > the considerations for changing an existing symbol between > EXPORT_SYMBOL or EXPORT_SYMBOL_GPL? I expect it would be awkward and > unwanted to set down hard rules, but a list of considerations that a > change proposal needs to address would at least help guide such > discussions. > > Not being a lawyer, I'm less interested in legal concerns, and more > the technical, code maintenance, and health of the kernel aspects of > what EXPORT_SYMBOL_GPL influences. > > Note, I am not available to travel to Edinburgh to lead this discussion. FWIW, I personally like to have a means to say "This code shall only be used by GPL code" for any code I contribute to the Linux kernel. I understand that this is completely non-technical. Guenter ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-13 19:43 [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL Dan Williams 2018-09-13 20:05 ` Guenter Roeck @ 2018-09-13 20:14 ` Greg KH 2018-09-13 21:04 ` Laurent Pinchart 1 sibling, 1 reply; 10+ messages in thread From: Greg KH @ 2018-09-13 20:14 UTC (permalink / raw) To: Dan Williams; +Cc: ksummit On Thu, Sep 13, 2018 at 12:43:15PM -0700, Dan Williams wrote: > Currently the only guidance we have about EXPORT_SYMBOL_GPL usage in > Documentation/ is: > > "It implies that the function is considered an internal implementation > issue, and not really an interface." > > The topics for a Maintainer Summit discussion are: > > 1/ The criteria "is considered an internal implementation issue" is > sufficiently vague and seems to lead to arbitrary and subjective > decisions by individual developers. Are there some objective technical > criteria we can apply? For example, the symbol consumes other > EXPORT_SYMBOL_GPL functionality, the symbol can effect kernel-wide > state / policy, or the symbol leaks internal implementation details > that are more unstable than typical EXPORT_SYMBOL apis. Any additional > subjective criteria to consider? For example, it would be better for > long term health of Linux if the consumers of a given API had the > EXPORT_SYMBOL_GPL-related encouragement to get their code upstream. > > 2/ With expanded criteria in hand the question then becomes what are > the considerations for changing an existing symbol between > EXPORT_SYMBOL or EXPORT_SYMBOL_GPL? I expect it would be awkward and > unwanted to set down hard rules, but a list of considerations that a > change proposal needs to address would at least help guide such > discussions. > > Not being a lawyer, I'm less interested in legal concerns, and more > the technical, code maintenance, and health of the kernel aspects of > what EXPORT_SYMBOL_GPL influences. > > Note, I am not available to travel to Edinburgh to lead this discussion. Nice topic, I like it! Being the one who used this symbol first (I think, maybe I am wrong), I'd be glad to lead this if others think it would be a good thing to formally document. And yes, I'm in the "let's document this thing somehow to keep maintainers from getting stuck in the middle" camp :) thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-13 20:14 ` Greg KH @ 2018-09-13 21:04 ` Laurent Pinchart 2018-09-14 6:32 ` Dave Airlie 0 siblings, 1 reply; 10+ messages in thread From: Laurent Pinchart @ 2018-09-13 21:04 UTC (permalink / raw) To: ksummit-discuss On Thursday, 13 September 2018 23:14:06 EEST Greg KH wrote: > On Thu, Sep 13, 2018 at 12:43:15PM -0700, Dan Williams wrote: > > Currently the only guidance we have about EXPORT_SYMBOL_GPL usage in > > Documentation/ is: > > > > "It implies that the function is considered an internal implementation > > issue, and not really an interface." > > > > The topics for a Maintainer Summit discussion are: > > > > 1/ The criteria "is considered an internal implementation issue" is > > sufficiently vague and seems to lead to arbitrary and subjective > > decisions by individual developers. Are there some objective technical > > criteria we can apply? For example, the symbol consumes other > > EXPORT_SYMBOL_GPL functionality, the symbol can effect kernel-wide > > state / policy, or the symbol leaks internal implementation details > > that are more unstable than typical EXPORT_SYMBOL apis. Any additional > > subjective criteria to consider? For example, it would be better for > > long term health of Linux if the consumers of a given API had the > > EXPORT_SYMBOL_GPL-related encouragement to get their code upstream. > > > > 2/ With expanded criteria in hand the question then becomes what are > > the considerations for changing an existing symbol between > > EXPORT_SYMBOL or EXPORT_SYMBOL_GPL? I expect it would be awkward and > > unwanted to set down hard rules, but a list of considerations that a > > change proposal needs to address would at least help guide such > > discussions. > > > > Not being a lawyer, I'm less interested in legal concerns, and more > > the technical, code maintenance, and health of the kernel aspects of > > what EXPORT_SYMBOL_GPL influences. > > > > Note, I am not available to travel to Edinburgh to lead this discussion. > > Nice topic, I like it! > > Being the one who used this symbol first (I think, maybe I am wrong), > I'd be glad to lead this if others think it would be a good thing to > formally document. > > And yes, I'm in the "let's document this thing somehow to keep > maintainers from getting stuck in the middle" camp :) As Guenter, I use EXPORT_SYMBOL_GPL as a political mean more than a technical mean. From a legal point of view it has always seemed a very grey area to me (especially since nobody has tested this particular in court). While a clear documentation would be useful to agree on a common meaning, I fear we will have many stakeholders trying to pull in different directions. >From a technical point of view, this is the first time I hear about EXPORT_SYMBOL_GPL implying an internal implementation instead of an interface. The sentence has been introduced in commit b6c17ea4eff360359d1741272028610035bb2da9 Author: Rusty Russell <rusty@rustcorp.com.au> Date: Fri Sep 9 13:10:11 2005 -0700 [PATCH] Update Documentation/DocBook/kernel-hacking.tmpl without any explanation in the commit message. That seems a dubious claim to me, given that EXPORT_SYMBOL_GPL allows linking a module to the kernel, in effect creating an API. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-13 21:04 ` Laurent Pinchart @ 2018-09-14 6:32 ` Dave Airlie 2018-09-14 7:08 ` Laurent Pinchart 0 siblings, 1 reply; 10+ messages in thread From: Dave Airlie @ 2018-09-14 6:32 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit On Fri, 14 Sep 2018 at 07:04, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > > On Thursday, 13 September 2018 23:14:06 EEST Greg KH wrote: > > On Thu, Sep 13, 2018 at 12:43:15PM -0700, Dan Williams wrote: > > > Currently the only guidance we have about EXPORT_SYMBOL_GPL usage in > > > Documentation/ is: > > > > > > "It implies that the function is considered an internal implementation > > > issue, and not really an interface." > > > > > > The topics for a Maintainer Summit discussion are: > > > > > > 1/ The criteria "is considered an internal implementation issue" is > > > sufficiently vague and seems to lead to arbitrary and subjective > > > decisions by individual developers. Are there some objective technical > > > criteria we can apply? For example, the symbol consumes other > > > EXPORT_SYMBOL_GPL functionality, the symbol can effect kernel-wide > > > state / policy, or the symbol leaks internal implementation details > > > that are more unstable than typical EXPORT_SYMBOL apis. Any additional > > > subjective criteria to consider? For example, it would be better for > > > long term health of Linux if the consumers of a given API had the > > > EXPORT_SYMBOL_GPL-related encouragement to get their code upstream. > > > > > > 2/ With expanded criteria in hand the question then becomes what are > > > the considerations for changing an existing symbol between > > > EXPORT_SYMBOL or EXPORT_SYMBOL_GPL? I expect it would be awkward and > > > unwanted to set down hard rules, but a list of considerations that a > > > change proposal needs to address would at least help guide such > > > discussions. > > > > > > Not being a lawyer, I'm less interested in legal concerns, and more > > > the technical, code maintenance, and health of the kernel aspects of > > > what EXPORT_SYMBOL_GPL influences. > > > > > > Note, I am not available to travel to Edinburgh to lead this discussion. > > > > Nice topic, I like it! > > > > Being the one who used this symbol first (I think, maybe I am wrong), > > I'd be glad to lead this if others think it would be a good thing to > > formally document. > > > > And yes, I'm in the "let's document this thing somehow to keep > > maintainers from getting stuck in the middle" camp :) > > As Guenter, I use EXPORT_SYMBOL_GPL as a political mean more than a technical > mean. From a legal point of view it has always seemed a very grey area to me > (especially since nobody has tested this particular in court). While a clear > documentation would be useful to agree on a common meaning, I fear we will > have many stakeholders trying to pull in different directions. > > From a technical point of view, this is the first time I hear about > EXPORT_SYMBOL_GPL implying an internal implementation instead of an interface. > The sentence has been introduced in > > commit b6c17ea4eff360359d1741272028610035bb2da9 > Author: Rusty Russell <rusty@rustcorp.com.au> > Date: Fri Sep 9 13:10:11 2005 -0700 > > [PATCH] Update Documentation/DocBook/kernel-hacking.tmpl > > without any explanation in the commit message. That seems a dubious claim to > me, given that EXPORT_SYMBOL_GPL allows linking a module to the kernel, in > effect creating an API. > https://lwn.net/Articles/154602/ Was the original advice Linus got and raised. Since then I think this advice has been sufficiently diluted by people lobbying for _GPL on any/all new exports, which means that we've probably neutered the actual usefulness of it from a legal point of view, instead of having a discussion about why a symbol is internal and hints at a derived work, we slapped it on a bunch of interfaces where it probably isn't applicable. (like refcounts had it for a while, anyone arguing that refcounts created a derived work was definitely neither legal nor technical, it was pure political.). Dave. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-14 6:32 ` Dave Airlie @ 2018-09-14 7:08 ` Laurent Pinchart 2018-09-16 12:58 ` Wolfram Sang 2018-09-16 22:15 ` Theodore Y. Ts'o 0 siblings, 2 replies; 10+ messages in thread From: Laurent Pinchart @ 2018-09-14 7:08 UTC (permalink / raw) To: Dave Airlie; +Cc: ksummit Hi Dave, On Friday, 14 September 2018 09:32:36 EEST Dave Airlie wrote: > On Fri, 14 Sep 2018 at 07:04, Laurent Pinchart wrote: > > On Thursday, 13 September 2018 23:14:06 EEST Greg KH wrote: > > > On Thu, Sep 13, 2018 at 12:43:15PM -0700, Dan Williams wrote: > > > > Currently the only guidance we have about EXPORT_SYMBOL_GPL usage in > > > > Documentation/ is: > > > > > > > > "It implies that the function is considered an internal implementation > > > > issue, and not really an interface." > > > > > > > > The topics for a Maintainer Summit discussion are: > > > > > > > > 1/ The criteria "is considered an internal implementation issue" is > > > > sufficiently vague and seems to lead to arbitrary and subjective > > > > decisions by individual developers. Are there some objective technical > > > > criteria we can apply? For example, the symbol consumes other > > > > EXPORT_SYMBOL_GPL functionality, the symbol can effect kernel-wide > > > > state / policy, or the symbol leaks internal implementation details > > > > that are more unstable than typical EXPORT_SYMBOL apis. Any additional > > > > subjective criteria to consider? For example, it would be better for > > > > long term health of Linux if the consumers of a given API had the > > > > EXPORT_SYMBOL_GPL-related encouragement to get their code upstream. > > > > > > > > 2/ With expanded criteria in hand the question then becomes what are > > > > the considerations for changing an existing symbol between > > > > EXPORT_SYMBOL or EXPORT_SYMBOL_GPL? I expect it would be awkward and > > > > unwanted to set down hard rules, but a list of considerations that a > > > > change proposal needs to address would at least help guide such > > > > discussions. > > > > > > > > Not being a lawyer, I'm less interested in legal concerns, and more > > > > the technical, code maintenance, and health of the kernel aspects of > > > > what EXPORT_SYMBOL_GPL influences. > > > > > > > > Note, I am not available to travel to Edinburgh to lead this > > > > discussion. > > > > > > Nice topic, I like it! > > > > > > Being the one who used this symbol first (I think, maybe I am wrong), > > > I'd be glad to lead this if others think it would be a good thing to > > > formally document. > > > > > > And yes, I'm in the "let's document this thing somehow to keep > > > maintainers from getting stuck in the middle" camp :) > > > > As Guenter, I use EXPORT_SYMBOL_GPL as a political mean more than a > > technical mean. From a legal point of view it has always seemed a very > > grey area to me (especially since nobody has tested this particular in > > court). While a clear documentation would be useful to agree on a common > > meaning, I fear we will have many stakeholders trying to pull in > > different directions. > > > > From a technical point of view, this is the first time I hear about > > EXPORT_SYMBOL_GPL implying an internal implementation instead of an > > interface. The sentence has been introduced in > > > > commit b6c17ea4eff360359d1741272028610035bb2da9 > > Author: Rusty Russell <rusty@rustcorp.com.au> > > Date: Fri Sep 9 13:10:11 2005 -0700 > > > > [PATCH] Update Documentation/DocBook/kernel-hacking.tmpl > > > > without any explanation in the commit message. That seems a dubious claim > > to me, given that EXPORT_SYMBOL_GPL allows linking a module to the > > kernel, in effect creating an API. > > https://lwn.net/Articles/154602/ > > Was the original advice Linus got and raised. > > Since then I think this advice has been sufficiently diluted by people > lobbying for _GPL on any/all new exports, which means that we've > probably neutered the actual usefulness of it from a legal point of > view, instead of having a discussion about why a symbol is internal > and hints at a derived work, we slapped it on a bunch of interfaces > where it probably isn't applicable. > > (like refcounts had it for a while, anyone arguing that refcounts > created a derived work was definitely neither legal nor technical, it > was pure political.). The argument that any module is a derived work of the kernel (at the very least when the module has been developed specifically for the Linux kernel) still hasn't been disproved, so this is a grey area as well. The argument is certainly political, but I don't see why it wouldn't be legal as well. I do agree that EXPORT_SYMBOL_GPL is useful though, as it makes the intent of the developer clear. As a mean of telling whether an interface is internal or not, however, I hae my doubts. -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-14 7:08 ` Laurent Pinchart @ 2018-09-16 12:58 ` Wolfram Sang 2018-09-16 22:15 ` Theodore Y. Ts'o 1 sibling, 0 replies; 10+ messages in thread From: Wolfram Sang @ 2018-09-16 12:58 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit [-- Attachment #1: Type: text/plain, Size: 537 bytes --] > The argument that any module is a derived work of the kernel (at the very > least when the module has been developed specifically for the Linux kernel) > still hasn't been disproved, so this is a grey area as well. The argument is > certainly political, but I don't see why it wouldn't be legal as well. > > I do agree that EXPORT_SYMBOL_GPL is useful though, as it makes the intent of > the developer clear. As a mean of telling whether an interface is internal or > not, however, I hae my doubts. I fully agree. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-14 7:08 ` Laurent Pinchart 2018-09-16 12:58 ` Wolfram Sang @ 2018-09-16 22:15 ` Theodore Y. Ts'o 2018-09-17 10:22 ` Mauro Carvalho Chehab 1 sibling, 1 reply; 10+ messages in thread From: Theodore Y. Ts'o @ 2018-09-16 22:15 UTC (permalink / raw) To: Laurent Pinchart; +Cc: ksummit On Fri, Sep 14, 2018 at 10:08:47AM +0300, Laurent Pinchart wrote: > > > > https://lwn.net/Articles/154602/ > > > > Was the original advice Linus got and raised. > > > > Since then I think this advice has been sufficiently diluted by people > > lobbying for _GPL on any/all new exports, which means that we've > > probably neutered the actual usefulness of it from a legal point of > > view, instead of having a discussion about why a symbol is internal > > and hints at a derived work, we slapped it on a bunch of interfaces > > where it probably isn't applicable. First of all, there's no real value (and probably some real harm) to have programmers trying to debate questions of legal interpretation. It would be much like asking lawyers to debug deadlocks in kernel code. It's not highest and best use of the people involved's talents. :-) Secondly, if you look very carefully at the above e-mail, the advice didn't say anything about what criteria should be used. In fact, the advice was to say that instead of trying to define the criteria (whether or not it is about internal implementation or anything else), what was important was that there *was* a difference, and that it be expressed explicitly in the code. In practice, it's been mostly been up to the person who originally implements the interface to decide whether it should be exported at all, and if so, whether it's exported using EXPORT_SYMBOL, or EXPORTED_SYMBOL_GPL. I don't think there has ever been a commonly agreed-upon set of criteria. My personal opinion is that a good dividing line is whether the interface is likely to stay ABI-compatible. After all, that's the promise that we make for userspace interfaces; once an interface is established, it can only be changed in a way that breaks userspace for extraordinary reasons (e.g., if it's the only way to deal with a security issue). And it's *clearly* understood that whether or not you believe the GPL can infect over any interface (which is a legal question for which the answer may vary in different jourisdictions), that it doesn't infect across the system call boundary. Now, obviously we don't make guarantees of absolute ABI stability of EXPORT_SYMBOL interfaces. But my personal take on it is that one of the essential differences between EXPORT_SYMBOL_GPL and EXPORT_SYMBOL is that EXPORT_SYMBOL_GPL is _more_ unstable than EXPORT_SYMBOL. Cheers, - Ted ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-16 22:15 ` Theodore Y. Ts'o @ 2018-09-17 10:22 ` Mauro Carvalho Chehab 2018-09-18 13:35 ` Steven Rostedt 0 siblings, 1 reply; 10+ messages in thread From: Mauro Carvalho Chehab @ 2018-09-17 10:22 UTC (permalink / raw) To: Theodore Y. Ts'o; +Cc: ksummit Em Sun, 16 Sep 2018 18:15:23 -0400 "Theodore Y. Ts'o" <tytso@mit.edu> escreveu: > On Fri, Sep 14, 2018 at 10:08:47AM +0300, Laurent Pinchart wrote: > > > > > > https://lwn.net/Articles/154602/ > > > > > > Was the original advice Linus got and raised. > > > > > > Since then I think this advice has been sufficiently diluted by people > > > lobbying for _GPL on any/all new exports, which means that we've > > > probably neutered the actual usefulness of it from a legal point of > > > view, instead of having a discussion about why a symbol is internal > > > and hints at a derived work, we slapped it on a bunch of interfaces > > > where it probably isn't applicable. > > First of all, there's no real value (and probably some real harm) to > have programmers trying to debate questions of legal interpretation. > It would be much like asking lawyers to debug deadlocks in kernel > code. It's not highest and best use of the people involved's talents. :-) > > Secondly, if you look very carefully at the above e-mail, the advice > didn't say anything about what criteria should be used. In fact, the > advice was to say that instead of trying to define the criteria > (whether or not it is about internal implementation or anything else), > what was important was that there *was* a difference, and that it be > expressed explicitly in the code. > > > In practice, it's been mostly been up to the person who originally > implements the interface to decide whether it should be exported at > all, and if so, whether it's exported using EXPORT_SYMBOL, or > EXPORTED_SYMBOL_GPL. I don't think there has ever been a commonly > agreed-upon set of criteria. > > My personal opinion is that a good dividing line is whether the > interface is likely to stay ABI-compatible. After all, that's the > promise that we make for userspace interfaces; once an interface is > established, it can only be changed in a way that breaks userspace for > extraordinary reasons (e.g., if it's the only way to deal with a > security issue). And it's *clearly* understood that whether or not > you believe the GPL can infect over any interface (which is a legal > question for which the answer may vary in different jourisdictions), > that it doesn't infect across the system call boundary. > > Now, obviously we don't make guarantees of absolute ABI stability of > EXPORT_SYMBOL interfaces. But my personal take on it is that one of > the essential differences between EXPORT_SYMBOL_GPL and EXPORT_SYMBOL > is that EXPORT_SYMBOL_GPL is _more_ unstable than EXPORT_SYMBOL. I have a different view. At least on media, we have a strong preference for EXPORT_SYMBOL_GPL() for kAPI, as it makes clear that we do expect them to be used by GPL compatible modules. We don't care much for symbols that are used inside drivers that got coded on different modules (we have a bunch of those usually on PCI/USB devices with multiple interfaces). We still have some symbols with EXPORTED_SYMBOL(). The reason is mainly historic. The symbols using it there are simply the ones that were either: - added to the Kernel before the advent of EXPORT_SYMBOL_GPL(), e. g. added before 2005; - during the period of time where we are getting familiar with EXPORT_SYMBOL_GPL(), and was discussing about its usage along the subsystem; - On places where all other symbols were already using EXPORT_SYMBOL() and we didn't make any major changes. So, developers just wanted to follow the existing module coding style and didn't want to take any bias with regards of their usage or not by non-GPL'd code. A common practice there is that, when someone rewrites the implementation of some symbol using EXPORT_SYMBOL() is to use EXPORT_SYMBOL_GPL() at the new implementation, to make clear about our desire that media modules should be GPL'd, but when we do simpler changes (even adding/removing parameters at the interface), we tend not to change it[1]. So, in practice, symbols with EXPORT_SYMBOL() are more stable, but just because them are usually for some legacy code that still works. [1] Usually just because EXPORT_SYMBOL*() comes after the function - it is easy to not remember touching it when we don't do a complete rewrite. Thanks, Mauro ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL 2018-09-17 10:22 ` Mauro Carvalho Chehab @ 2018-09-18 13:35 ` Steven Rostedt 0 siblings, 0 replies; 10+ messages in thread From: Steven Rostedt @ 2018-09-18 13:35 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: ksummit On Mon, 17 Sep 2018 07:22:50 -0300 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote: > A common practice there is that, when someone rewrites the implementation > of some symbol using EXPORT_SYMBOL() is to use EXPORT_SYMBOL_GPL() at > the new implementation, to make clear about our desire that media modules > should be GPL'd, but when we do simpler changes (even adding/removing > parameters at the interface), we tend not to change it[1]. To add to this bike-shed discussion, my view is that if the function is unique to Linux, it should be EXPORT_SYMBOL_GPL(), and if it is a common functionality among all operating systems (like request_irq()) then I would consider it EXPORT_SYMBOL(). The tracing infrastructure that we have is unique to Linux and thus all functions are EXPORT_SYMBOL_GPL(). Proprietary modules can't even add trace events without breaking that. Although they could use kprobes and function based events (when we finish that). -- Steve ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-09-18 13:36 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-13 19:43 [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL Dan Williams 2018-09-13 20:05 ` Guenter Roeck 2018-09-13 20:14 ` Greg KH 2018-09-13 21:04 ` Laurent Pinchart 2018-09-14 6:32 ` Dave Airlie 2018-09-14 7:08 ` Laurent Pinchart 2018-09-16 12:58 ` Wolfram Sang 2018-09-16 22:15 ` Theodore Y. Ts'o 2018-09-17 10:22 ` Mauro Carvalho Chehab 2018-09-18 13:35 ` Steven Rostedt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.