Re: [PATCH 1/2] pwm: lpss: Move namespace import into a header

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Wed, Dec 04, 2024 at 12:38:49AM +0100, Uwe Kleine-König wrote:
> On Wed, Dec 04, 2024 at 12:28:23AM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 03, 2024 at 10:32:17PM +0100, Uwe Kleine-König wrote:
> > > On Tue, Dec 03, 2024 at 09:12:36PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Dec 03, 2024 at 06:16:14PM +0100, Uwe Kleine-König wrote:

...

> > > > The header must not provide any module importing features as it effectively
> > > > diminishes the point of namespace. Any (ab)user can include just a header and
> > > > be okay with that.
> > > 
> > > Huh? Any abuser can also just do the IMPORT_NS statement? Module
> > > namespaces are not a safeguard against bad code? So I don't see why
> > > making it simple for the regular users should be the wrong choice.
> > > 
> > > Actually I think this is very elegant because this way all needs to use
> > > these symbols (i.e. prototype and namespace) are in a single place and
> > > users just do the #include and get all the preconditions.
> > 
> > Recent LWN https://lwn.net/Articles/998221/ article describes in more details
> > what I implied under abuser here.
> 
> Ok. But I don't see how this supports your case. Independent of where
> the import for a given namespace happens, you can see the used
> namespaces in modinfo and that is the only place where suspicious
> imports can be noted reliably. And MODULE_foo isn't relevant here as the
> namespace of the pwm-lpss driver combo is used in several modules.

The initial point that the (ab)users will be visible at review stage.
Yes, runtime restrictions are more difficult to enforce.

> I thought the point of namespaces is grouping of symbols and reduction
> of the set of globally available symbols to speed up module loading.
> I didn't have "duplicate IMPORT_NS statements to make it harder for bad
> out-of-tree code" on my radar and that shouldn't be a motivation if the
> price is that in-tree code faces the same constraints IMHO.
> 
> And I'm pretty sure, we won't prevent a bad actor from successfully
> using a symbol they should not, just because they need an include *and*
> an import.
> 
> Am I missing something?

They may not need the include actually, as they can just tell the compiler with
extern keyword to look for a prototype somewhere else. In any case let's
return to the main topic here. My proposal is to add the respective module
namespace import into pin control driver.

-- 
With Best Regards,
Andy Shevchenko