linux-kernel - Re: [PATCH v1 2/9] pwm: lpss: Move exported symbols to PWM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YxipACrMCQbE4xmk@smile.fi.intel.com>
Date:   Wed, 7 Sep 2022 17:21:52 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org,
        Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH v1 2/9] pwm: lpss: Move exported symbols to PWM_LPSS
 namespace

On Wed, Sep 07, 2022 at 11:11:44AM +0200, Uwe Kleine-König wrote:
> On Tue, Sep 06, 2022 at 10:57:28PM +0300, Andy Shevchenko wrote:

> >  MODULE_DESCRIPTION("PWM platform driver for Intel LPSS");
> >  MODULE_LICENSE("GPL v2");
> > +MODULE_IMPORT_NS(PWM_LPSS);
> >  MODULE_ALIAS("platform:pwm-lpss");
> 
> While it's not wrong to add the IMPORT_NS statement to each file, I'd
> had added it to pwm-lpss.h. IMHO that makes sense as every includer of
> that header needs that IMPORT_NS to actually use the symbols declared
> there.

If you have an optional dependency you may not need to include namespace
to avoid dragging it for peanuts.

...

> > -EXPORT_SYMBOL_GPL(pwm_lpss_probe);
> > +EXPORT_SYMBOL_NS_GPL(pwm_lpss_probe, PWM_LPSS);
> 
> There is something possible with more magic:

I know.

> 	#define DEFAULT_SYMBOL_NAMESPACE PWM_LPSS
> 
> which you only need once in pwm-lpss.c and then all exports use that
> namespace. (And if you pick up my suggestion for patch 1 you also
> benefit from that.)

For a single export (even for a few of them) it's an overkill.

Taking above into consideration I don't think we need to alter
a proposed change.

Thanks for review!

-- 
With Best Regards,
Andy Shevchenko