On Tue, Feb 11, 2025 at 06:53:17PM +0000, Mark Brown wrote: > On Tue, Feb 11, 2025 at 07:45:30PM +0100, Uwe Kleine-König wrote: > > > There was a similar discussion some time ago about the lpss pwm driver > > (https://lore.kernel.org/linux-pwm/Z09YJGifvpENYNPy@xxxxxxxxxxxxxxxxxx/). > > The arguments that you didn't accept back then already are similar to > > the ones that were brought forward here. > > The TL;DR; is: Adding MODULE_IMPORT_NS() to a header makes it easier for > > code to use the exported symbols. Yes, that includes abusers of the > > code. > > > But if you mostly care about the regular users of an API/ABI, making > > things easy for those is the thing that matters. Agreed, if you think > > that module namespaces are primarily a line of defence against abusers, > > adding the import to the header weakens that defence (a bit). However a > > typical header includes function prototypes and macros. Those also make > > it easier for abusers. With your argumentation we better don't create > > headers at all? > > > There are other benefits of module namespaces like reducing the set of > > globally available symbols which speeds up module loading or the > > ability to see in the module meta data that a namespace is used. > > FWIW I fully endorse what Uwe is saying here, forcing every user of the > API to separately import the symbols seems more likely to create > busywork than to avoid problems. I see. Another problem that comes to my mind just now is the module.h to be included by every header that wants to use MODULE_*() macro. Maybe someone wants to split mod_namespace.h to decrease an added chaos? -- With Best Regards, Andy Shevchenko