From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Daniel Gomez <da.gomez@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Matthias Maennich <maennich@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Luis Chamberlain <mcgrof@kernel.org>,
Petr Pavlu <petr.pavlu@suse.com>,
Sami Tolvanen <samitolvanen@google.com>,
Daniel Gomez <da.gomez@samsung.com>,
Masahiro Yamada <masahiroy@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Christoph Hellwig <hch@infradead.org>,
Peter Zijlstra <peterz@infradead.org>,
David Hildenbrand <david@redhat.com>,
Shivank Garg <shivankg@amd.com>,
"Jiri Slaby (SUSE)" <jirislaby@kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-modules@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
Date: Sun, 13 Jul 2025 10:31:10 +0200 [thread overview]
Message-ID: <2025071355-debunk-sprang-e1ad@gregkh> (raw)
In-Reply-To: <b9b74600-4467-4c76-aa41-0a36b1cce1f4@kernel.org>
On Sat, Jul 12, 2025 at 08:26:17PM +0200, Daniel Gomez wrote:
> On 11/07/2025 16.05, Vlastimil Babka wrote:
> > Christoph suggested that the explicit _GPL_ can be dropped from the
> > module namespace export macro, as it's intended for in-tree modules
> > only. It would be possible to resrict it technically, but it was pointed
> > out [2] that some cases of using an out-of-tree build of an in-tree
> > module with the same name are legitimate. But in that case those also
> > have to be GPL anyway so it's unnecessary to spell it out.
> >
> > Link: https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/ [1]
> > Link: https://lore.kernel.org/all/CAK7LNATRkZHwJGpojCnvdiaoDnP%2BaeUXgdey5sb_8muzdWTMkA@mail.gmail.com/ [2]
> > Suggested-by: Christoph Hellwig <hch@infradead.org>
> > Reviewed-by: Shivank Garg <shivankg@amd.com>
> > Acked-by: Christian Brauner <brauner@kernel.org>
> > Acked-by: David Hildenbrand <david@redhat.com>
> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> > ---
> > Christian asked [1] for EXPORT_SYMBOL_FOR_MODULES() without the _GPL_
> > part to avoid controversy converting selected existing EXPORT_SYMBOL().
> > Christoph argued [2] that the _FOR_MODULES() export is intended for
> > in-tree modules and thus GPL is implied anyway and can be simply dropped
> > from the export macro name. Peter agreed [3] about the intention for
> > in-tree modules only, although nothing currently enforces it.
> >
> > It seemed straightforward to add this enforcement, so v1 did that. But
> > there were concerns of breaking the (apparently legitimate) usecases of
> > loading an updated/development out of tree built version of an in-tree
> > module.
> >
> > So leave out the enforcement part and just drop the _GPL_ from the
> > export macro name and so we're left with EXPORT_SYMBOL_FOR_MODULES()
> > only. Any in-tree module used in an out-of-tree way will have to be GPL
> > anyway by definition.
> >
> > Current -next has some new instances of EXPORT_SYMBOL_GPL_FOR_MODULES()
> > in drivers/tty/serial/8250/8250_rsa.c by commit b20d6576cdb3 ("serial:
> > 8250: export RSA functions"). Hopefully it's resolvable by a merge
> > commit fixup and we don't need to provide a temporary alias.
> >
> > [1] https://lore.kernel.org/all/20250623-warmwasser-giftig-ff656fce89ad@brauner/
> > [2] https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/
> > [3] https://lore.kernel.org/all/20250623142836.GT1613200@noisy.programming.kicks-ass.net/
> > ---
> > Changes in v2:
> > - drop the patch to restrict module namespace export for in-tree modules
> > - fix a pre-existing documentation typo (Nicolas Schier)
> > - Link to v1: https://patch.msgid.link/20250708-export_modules-v1-0-fbf7a282d23f@suse.cz
> > ---
> > Documentation/core-api/symbol-namespaces.rst | 8 ++++----
> > fs/anon_inodes.c | 2 +-
> > include/linux/export.h | 2 +-
> > 3 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
> > index 32fc73dc5529e8844c2ce2580987155bcd13cd09..6f7f4f47d43cdeb3b5008c795d254ca2661d39a6 100644
> > --- a/Documentation/core-api/symbol-namespaces.rst
> > +++ b/Documentation/core-api/symbol-namespaces.rst
> > @@ -76,8 +76,8 @@ A second option to define the default namespace is directly in the compilation
> > within the corresponding compilation unit before the #include for
> > <linux/export.h>. Typically it's placed before the first #include statement.
> >
> > -Using the EXPORT_SYMBOL_GPL_FOR_MODULES() macro
> > ------------------------------------------------
> > +Using the EXPORT_SYMBOL_FOR_MODULES() macro
> > +-------------------------------------------
> >
> > Symbols exported using this macro are put into a module namespace. This
> > namespace cannot be imported.
>
> The new naming makes sense, but it breaks the pattern with _GPL suffix:
>
> * EXPORT_SYMBOL(sym)
> * EXPORT_SYMBOL_GPL(sym)
> * EXPORT_SYMBOL_NS(sym, ns)
> * EXPORT_SYMBOL_NS_GPL(sym, ns)
> * EXPORT_SYMBOL_FOR_MODULES(sym, mods)
>
> So I think when reading this one may forget about the _obvious_ reason. That's
> why I think clarifying that in the documentation would be great. Something like:
>
> Symbols exported using this macro are put into a module namespace. This
> namespace cannot be imported. And it's implicitly GPL-only as it's only intended
> for in-tree modules.
s/implicitly/explicitly/
thanks,
greg k-h
next prev parent reply other threads:[~2025-07-13 8:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 14:05 [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES Vlastimil Babka
2025-07-11 14:13 ` Nicolas Schier
2025-07-12 18:26 ` Daniel Gomez
2025-07-13 8:31 ` Greg Kroah-Hartman [this message]
2025-07-14 7:09 ` Vlastimil Babka
2025-07-14 8:08 ` Christian Brauner
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=2025071355-debunk-sprang-e1ad@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=da.gomez@kernel.org \
--cc=da.gomez@samsung.com \
--cc=david@redhat.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jirislaby@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=maennich@google.com \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=peterz@infradead.org \
--cc=petr.pavlu@suse.com \
--cc=samitolvanen@google.com \
--cc=sfr@canb.auug.org.au \
--cc=shivankg@amd.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.