|| ||Anton Altaparmakov <anton-AT-tuxera.com> |
|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Christoph Hellwig <hch-AT-infradead.org> |
|| ||Direct i/o changes break all non-GPL file systems |
|| ||Wed, 8 Feb 2012 00:07:15 +0000|
|| ||Szabolcs Szakacsits <szaka-AT-tuxera.com>,
|| ||Article, Thread
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
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!
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/
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)