lkml.org 
[lkml]   [2012]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Direct i/o changes break all non-GPL file systems
On Fri, Feb 10, 2012 at 11:28:27AM -0800, Linus Torvalds wrote:
> On Tue, Feb 7, 2012 at 5:51 PM, Andreas Dilger <adilger@dilger.ca> wrote:
> >
> > This doesn't affect me directly, since Lustre is itself a GPL filesystem,
> > but it does seem a bit harsh for such a minor amount of functionality.
>
> It also wasn't documented in the commit or apparently even intentional.
>
> > Looking at inode_dio_wait(), there isn't anything in there that couldn't
> > be implemented without using that GPL-only symbol export. ?Both inode_dio_wait()
> > and __inode_dio_wait() use only functions that are themselves EXPORT_SYMBOL()
> > (i.e. not GPL-only) and locally accessible structures (inode->i_dio_count
> > and inode->i_state), so I don't see any benefit or reason in making
> > inode_dio_wait() itself GPL.
>
> Yes. I suspect we should just remove the _GPL part. Christoph, Al?

I'm all for it; TBH, I simply missed _GPL on those back then. As far as I'm
concerned, there are 3 cases:
1) it's a part of general-purpose API and it does make sense for
modules; use EXPORT_SYMBOL
2) it's a kernel-internal thing that is not used by in-tree modules
and should not be used by any modules; don't export it at all
3) it's a layering violation that unfortunately still is needed for
an in-tree module. The *only* case where I'd consider EXPORT_SYMBOL_GPL
borderline useful, as a bad proxy for EXPORT_SYMBOL_DONT_USE_OUT_OF_TREE.

It's Christoph's code, though, so I'm not happy with just going ahead and
ripping that _GPL off those exports. Christoph?

And folks, for the future, do not use ..._GPL on VFS exports unless you have
a damn good reason to discourage the use in out-of-tree modules in general.
Which needs to be clearly documented.


\
 
 \ /
  Last update: 2012-02-10 22:23    [W:0.042 / U:16.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site