[OpenAFS-devel] Re: Compiling kernel module for 2.6.28.1

[Jeffrey Hutzelman]

--On Monday, January 26, 2009 12:32:52 AM -0500 Chaskiel Grundman 
<cg2v@andrew.cmu.edu> wrote:

>
>>> use. Unfortunately that, and the relicensing of a load of the sunrpc
>>> functions to also be GPL only, means that the Linux NFS translator is
>>> pretty much dead in the water.
>>
>> Which reminds me; have we complained at lkml yet?
>> ISTR Linus saying that existing interfaces would not be relicensed in
>> this  fashion.
>
> It seems that this (the sunrpc stuff) isn't about licensing. It's about
> "is this an interface" I can't find a discussion thread, but the commit
> log says 'The sunrpc server code should not be used by out-of-tree
> modules'. Why whoever feels the need to make it explicit I don't know.

Ah, so someone still doesn't understand that "GPL only" and "in-tree only" 
are not the same thing, and that there is no technical measure for 
enforcing the latter.  Yay.

In the past it has sometimes been possible to get such changes reverted, 
but those have generally been cases where GPL_ONLY was used to make a 
symbol private and one of the in-tree references was a macro or inline 
function that was intended to remain public.  Still, if we haven't tried, 
we should.

Of course, our particular usage is rather hideous, aimed mostly at getting 
the original client identity so that we can implement per-client PAG's.  I 
don't remember for sure, but I think we may be able to manage without the 
authtab interception if we're willing to live without this feature.

> As far as d_obtain_alias is concerned, it seems that it is intended for
> 'Obtain(ing) a dentry for an inode resulting from NFS filehandle
> conversion or similar open by handle operations.' Since it was already
> the case that non-GPL filesystems had a tough time being exporters, this
> isn't a big change.

As someone who made a non-GPL filesystem be an exporter, I don't recall 
having any particular difficulties that were related to license issues.

-- Jeff