On Wed, Mar 19, 2014 at 01:02:55PM -0500, Andrew Deason wrote: > On Wed, 19 Mar 2014 12:13:24 -0400 > "J. Bruce Fields" <[email protected]> wrote: > > As for GPL_ONLY symbols I think it's certainly worth compiling a list > > and asking. Obviously the kernel community (myself included!) would > > be much happier to see effort invested on upstream code. But obvious > > oversights (d_materialise_unique looks like one) do get fixed. > > Where would such a request go? LKML?
Yes, I'd recommend including [email protected] and [email protected]. > Does anyone on the openafs side > here know if we've ever asked for that before, or have any other > opinions here? I assume Red Hat or any downstream will not / cannot > change any such restrictions that upstream does not change. > > If it's not clear, though, this isn't a simple oversight or something > that happens to be GPLONLY when other similar symbols are not. This is > basically an entire subsystem that as far as I know has always been > GPL-restricted. That suggested to me that the changes of changing the > restriction are around zero, but I honestly don't really understand the > various motivations to restrict or unrestrict interfaces, so I can't > pretend to have any idea what will actually happen. I don't know much about it either, honestly. Looking around, all I can find under Documentation/ is [EXPORT_SYMBOL_GPL] implies that the function is considered an internal implementation issue, and not really an interface. Looking through the git logs it seems the most common justifications for downgrading to EXPORT_SYMBOL are: - function is logical part of an api the rest of which are non-gpl exports. - function replaced something that was previously a non-GPL export that people depended on. I'd also think things like "api changes rarely", "needed by common classes of out-of-tree modules" (e.g. filesystems), or "similar to interfaces provided by other kernels" might all weigh in favor. But I don't really know. Anyway, the only answers may well be "stop bothering us with your out-of-tree module and help us get proper AFS support upstream". But you don't know if you don't ask.... --b. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
