Re: [PATCH v2] export: fix string handling of namespace in EXPORT_SYMBOL_NS

[Greg Kroah-Hartman]

On Wed, Apr 27, 2022 at 11:29:19PM +0900, Masahiro Yamada wrote:
> On Wed, Apr 27, 2022 at 6:06 PM Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Commit c3a6cf19e695 ("export: avoid code duplication in
> > include/linux/export.h") broke the ability for a defined string to be
> > used as a namespace value.
> 
> In hindsight, this was a bad idea.
> 
> 
> EXPORT_SYMBOL_NS_GPL(dw_spi_resume_host, "SPI_DW_CORE")
> 
>    is much much better than:
> 
> EXPORT_SYMBOL_NS_GPL(dw_spi_resume_host, SPI_DW_CORE)

I agree, but it's really not that big of a deal.  We could change it if
you want.

> ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_STORAGE
> 
> is also a bad idea.

That's not such a bad idea as it lets you set a namespace for a
directory and below easily.  What would you want to use instead?

> When you look at EXPORT_SYMBOL_GPL() in C files, you will not be
> aware of the presence of the namespace.

It's easy to tell when things do not link properly :)

> Anyway, it is presumably too late to fix it.

Not really, the number of in-kernel users are still small and can be
changed if you like.  External users can update when they hit the change
as well, not a big deal.

Other than using a string for the namespace definition, what would you
like to see done differently?

> >  Fix this up by using stringify to properly
> > encode the namespace name.
> >
> > Fixes: c3a6cf19e695 ("export: avoid code duplication in include/linux/export.h")
> > Cc: Miroslav Benes <mbenes@xxxxxxx>
> > Cc: Emil Velikov <emil.l.velikov@xxxxxxxxx>
> > Cc: Jessica Yu <jeyu@xxxxxxxxxx>
> > Cc: Quentin Perret <qperret@xxxxxxxxxx>
> > Cc: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
> 
> This email is no longer valid.

Ah, sorry about that.

> Feel free to replace it with
> 
> Reviewed-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>

Will do, thanks!

greg k-h