From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andreas Dilger <adilger@dilger.ca>,
Anton Altaparmakov <anton@tuxera.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Szabolcs Szakacsits <szaka@tuxera.com>,
Janne Kalliom?ki <janne@tuxera.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Direct i/o changes break all non-GPL file systems
Date: Fri, 10 Feb 2012 21:19:48 +0000 [thread overview]
Message-ID: <20120210211946.GJ23916@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFyBAiZ3khqQiSU0OBafMABsAzdU5DLzZvaM_Et52Wte5w@mail.gmail.com>
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.
next prev parent reply other threads:[~2012-02-10 21:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-08 0:07 Direct i/o changes break all non-GPL file systems Anton Altaparmakov
2012-02-08 0:15 ` Alan Cox
2012-02-08 0:28 ` Anton Altaparmakov
2012-02-08 1:51 ` Andreas Dilger
2012-02-10 19:28 ` Linus Torvalds
2012-02-10 21:19 ` Al Viro [this message]
2012-02-11 16:18 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120210211946.GJ23916@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adilger@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=anton@tuxera.com \
--cc=hch@infradead.org \
--cc=janne@tuxera.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=szaka@tuxera.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).