[OpenAFS-devel] Re: OpenAFS client crashes on RHEL 5.10 and RHEL 6.5

[J. Bruce Fields]

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" <bfields@redhat.com> 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 linux-kernel@vger.kernel.org and
linux-fsdevel@vger.kernel.org.

> 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.