Hi Linus, Andrew, Christoph,
With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait() and inode_dio_done()) which are EXPORT_SYMBOL_GPL() thus they cannot be used by non-GPL file systems and further inode_dio_wait() was pushed from notify_change() into the file system ->setattr() method but no non-GPL file system can make this call.
That means non-GPL file systems cannot exist any more unless they do not use any VFS functionality related to reading/writing as far as I can tell or at least as long as they want to implement direct i/o.
What are commercial file systems meant to do now?
For example Tuxera exFAT uses the generic write code which means that read/write use the generic direct_IO functions however Tuxera exFAT's setattr() method cannot call inode_dio_wait() and there are places where exfat_truncate() is called directly with i_alloc_sem held and now this needs to be replaced with calls to inode_dio_wait() but we cannot do that as the function is GPL only.
Previously when APIs have been changed that were accessible to non-GPL modules it was made sure those APIs remained that way but this does not appear to be the case here.
Do all non-GPL file systems now really have to re-implement the entire read-write code paths for themselves for the sake of two GPL only exports in the direct i/o code? That seems a bit harsh!
Have I missed something? If not would you accept a patch to change the two needed GPL only symbols into EXPORT_SYMBOL() ones?
Thanks a lot in advance!
Best regards,
Anton
--
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Senior Kernel Developer, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer, http://www.linux-ntfs.org/
On Wed, 8 Feb 2012 00:07:15 +0000
Anton Altaparmakov <[email protected]> wrote:
> Hi Linus, Andrew, Christoph,
>
> With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait() and inode_dio_done()) which are EXPORT_SYMBOL_GPL() thus they cannot be used by non-GPL file systems and further inode_dio_wait() was pushed from notify_change() into the file system ->setattr() method but no non-GPL file system can make this call.
I'm advised by my lawyer that when this occurs that I should always
inform the other party the following
"For a Linux kernel containing any code I own the code is under the GNU
public license v2 (in some cases or later), I have never given permission
for that code to be used as part of a combined or derivative work which
contains binary chunks. I have never said that modules are somehow
magically outside the GPL and I am doubtful that in most cases a work
containing binary modules for a Linux kernel is compatible with the
licensing, although I accept there may be some cases that it is."
So unless your code is remarkably non-derivative I don't see that
anything has changed.
Hi Alan,
I don't really want to get into this discussion due to the likelihood of people using it as an excuse to start a flamewar which we can really do without.
Linus has previously stated that he is happy for binary kernel modules to exist and I believe that a kernel module calling EXPORT_SYMBOL() functions is the equivalent of a user space program executing system calls. I do not believe this has even been decided in court so let us please not start a flamewar on the subject! I am sure both points of view have their merits but unless they are tested in court there is no point in wasting everyones time discussing the subject to death. That has been done many times before ad nauseum.
Can we please let this sort of debate be and just focus on the question whether this breakage for non-GPL modules was intentional or accidental and if the latter whether the author, namely Christoph, would be willing to reconsider his choice and allow the symbols to become generically exported, in which case we can return to the state we had before by exporting the two symbols to all modules.
Thank you (and apologise for top posting).
Best regards,
Anton
On 8 Feb 2012, at 00:15, Alan Cox wrote:
> On Wed, 8 Feb 2012 00:07:15 +0000
> Anton Altaparmakov <[email protected]> wrote:
>
>> Hi Linus, Andrew, Christoph,
>>
>> With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait() and inode_dio_done()) which are EXPORT_SYMBOL_GPL() thus they cannot be used by non-GPL file systems and further inode_dio_wait() was pushed from notify_change() into the file system ->setattr() method but no non-GPL file system can make this call.
>
> I'm advised by my lawyer that when this occurs that I should always
> inform the other party the following
>
> "For a Linux kernel containing any code I own the code is under the GNU
> public license v2 (in some cases or later), I have never given permission
> for that code to be used as part of a combined or derivative work which
> contains binary chunks. I have never said that modules are somehow
> magically outside the GPL and I am doubtful that in most cases a work
> containing binary modules for a Linux kernel is compatible with the
> licensing, although I accept there may be some cases that it is."
>
>
>
> So unless your code is remarkably non-derivative I don't see that
> anything has changed.
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
On 2012-02-07, at 5:28 PM, Anton Altaparmakov wrote:
> Linus has previously stated that he is happy for binary kernel modules to exist and I believe that a kernel module calling EXPORT_SYMBOL() functions is the equivalent of a user space program executing system calls. I do not believe this has even been decided in court so let us please not start a flamewar on the subject! I am sure both points of view have their merits but unless they are tested in court there is no point in wasting everyones time discussing the subject to death. That has been done many times before ad nauseum.
>
> Can we please let this sort of debate be and just focus on the question whether this breakage for non-GPL modules was intentional or accidental and if the latter whether the author, namely Christoph, would be willing to reconsider his choice and allow the symbols to become generically exported, in which case we can return to the state we had before by exporting the two symbols to all modules.
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.
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.
Cheers, Andreas
> On 8 Feb 2012, at 00:15, Alan Cox wrote:
>> On Wed, 8 Feb 2012 00:07:15 +0000
>> Anton Altaparmakov <[email protected]> wrote:
>>
>>> Hi Linus, Andrew, Christoph,
>>>
>>> With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait() and inode_dio_done()) which are EXPORT_SYMBOL_GPL() thus they cannot be used by non-GPL file systems and further inode_dio_wait() was pushed from notify_change() into the file system ->setattr() method but no non-GPL file system can make this call.
>>
>> I'm advised by my lawyer that when this occurs that I should always
>> inform the other party the following
>>
>> "For a Linux kernel containing any code I own the code is under the GNU
>> public license v2 (in some cases or later), I have never given permission
>> for that code to be used as part of a combined or derivative work which
>> contains binary chunks. I have never said that modules are somehow
>> magically outside the GPL and I am doubtful that in most cases a work
>> containing binary modules for a Linux kernel is compatible with the
>> licensing, although I accept there may be some cases that it is."
>>
>>
>>
>> So unless your code is remarkably non-derivative I don't see that
>> anything has changed.
>
>
> --
> Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
> Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
> Linux NTFS maintainer, http://www.linux-ntfs.org/
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
On Tue, Feb 7, 2012 at 5:51 PM, Andreas Dilger <[email protected]> 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?
Linus
On Fri, Feb 10, 2012 at 11:28:27AM -0800, Linus Torvalds wrote:
> On Tue, Feb 7, 2012 at 5:51 PM, Andreas Dilger <[email protected]> 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.
Al Viro <[email protected]> writes:
> 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.
I had the namespace patches to make this explicit some time ago
http://lwn.net/Articles/259839/
This allows to export specific symbols only for special other modules,
in case it's only a single module that needs a "backdoor"
I can look at resubmitting the patchkit.
-Andi
--
[email protected] -- Speaking for myself only