On Fri, Sep 19, 2025 at 10:20:29AM -0500, David Lechner wrote:

On 9/19/25 10:13 AM, Greg KH wrote:

quoted

On Fri, Sep 19, 2025 at 10:05:28AM -0500, David Lechner wrote:

quoted

On 9/19/25 8:59 AM, Greg KH wrote:

quoted

On Thu, Sep 18, 2025 at 10:00:29PM +0300, Andy Shevchenko wrote:

quoted

I,o.w. I principally disagree on putting MODULE_IMPORT_NS() into the header
file.

Yes, please never do that, it defeats the purpose of module namespaces
completly.  If you don't want to have module namespaces, don't use them
for your subsytem.  Don't use them and then make them moot by putting
MODULE_IMPORT_NS() in the .h file for the symbols as that's pointless.

thanks,

greg k-h

Could someone suggest some additional explanation to add to
Documentation/core-api/symbol-namespaces.rst to explain the
reasoning behind this?

Right now, the only part of that document that say _why_ we have
module namespces says:

	That is useful for documentation purposes (think of the
	SUBSYSTEM_DEBUG namespace) as well as for limiting the
	availability of a set of symbols for use in other parts
	of the kernel.

So I don't see the connection between this explanation and and:

	[Putting MODULE_IMPORT_NS() into the header] defeats
	the purpose of module namespaces completely.

I am guilty of putting it in a header, so if I need to fix that
I would like to actually understand why first. Andy has mentioned
something about potential abuses, but without any example, I haven't
been able to understand what this would actually actually look like.
Or maybe there is some other reason that Greg is thinking of that
hasn't been mentioned yet?

Let me turn it around, _why_ would you want your exports in a namespace
at all if you just are putting a MODULE_IMPORT_NS() in the .h file at
the same time?  What is this giving you at all compared to just a normal
MODULE_EXPORT() marking for your exports?

I know what it gives me when I don't put it in a .h file, but I think
that might be different from what you are thinking here :)

thanks,

greg k-h

Up to now, my (naive) understanding was that the point module namespaces
is to reduce the number of symbols in the global namespace because having
too many symbols there was starting to cause problems. So moving symbols
to another namespace was a "good thing".

Yes, it is a "good thing" overall, but by just making all of your
symbols in a namespace, and then including it in the .h file, that does
the same exact thing as before (i.e. anyone that includes that .h file
puts the symbols into the global namespace with that prefix.)

Ideally, the goal was to be able to easily see in a module, what symbol
namespaces they depend on, which requires them to put MODULE_IMPORT_NS()
in the module to get access to those symbols.  dmabuf has done this very
well, making it obvious to the maintainers of that subsystem that they
should be paying attention to those users.

For other "tiny" subsystems, it just slots away their symbols so that no
one else should ever be using them, and it makes it blindingly obvious
if they do.  For example, the usb-storage symbols, anyone that does:
	MODULE_IMPORT_NS("USB_STORAGE");
had better be living in drivers/usb/storage/ otherwise I need to have a
word with those offenders :)

So it's a way of "tidying" up things, and to make things more explicit
than just having to rely on searching a tree and looking for .h include
usage.  Right now, you are kind of defeating that by just allowing a .h
to be included and you don't get any benifit of being able to watch out
for who is actually using those symbols overall.

Hope this helps,

greg k-h

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy