Re: [PATCH v3 10/11] RFC: usb-storage: export symbols in USB_STORAGE namespace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 21, 2019 at 04:13:29PM -0700, Christoph Hellwig wrote:
On Wed, Aug 21, 2019 at 12:49:25PM +0100, Matthias Maennich wrote:
Modules using these symbols are required to explicitly import the
namespace. This patch was generated with the following steps and serves
as a reference to use the symbol namespace feature:

 1) Define DEFAULT_SYMBOL_NAMESPACE in the corresponding Makefile
 2) make  (see warnings during modpost about missing imports)
 3) make nsdeps

Instead of a DEFAULT_SYMBOL_NAMESPACE definition, the EXPORT_SYMBOL_NS
variants can be used to explicitly specify the namespace. The advantage
of the method used here is that newly added symbols are automatically
exported and existing ones are exported without touching their
respective EXPORT_SYMBOL macro expansion.

So what is USB_STORAGE here?  It isn't a C string, so where does it
come from?  To me using a C string would seem like the nicer interface
vs a random cpp symbol that gets injected somewhere.

To be honest, I would also prefer an interface that uses C strings or
literals for the new EXPORT_SYMBOLS* macros:

 EXPORT_SYMBOL_NS(mysym, "USB_STORAGE");

 or

 const char USB_STORAGE_NS[] = "USB_STORAGE";
 EXPORT_SYMBOL_NS(mysym, USB_STORAGE_NS);

The DEFAULT_SYMBOL_NAMESPACE define within Makefiles would get a bit
more verbose in that case to express the literal:
 ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE="\"USB_STORAGE\""


The main reason against that, is, that in the expansion of
EXPORT_SYMBOL_NS, we define the ksymtab entry, which name is
constructed partly by the name of the namespace:

  static const struct kernel_symbol __ksymtab_##sym##__##ns  ...
                                                       ^^^^

For that we depend on a cpp symbol to construct the name. I am not sure
there is a reasonable way of getting rid of that without ending up
constructing the ksymtab entries completely in asm as it is already done
in case of PREL32_RELOCATIONS. But I am happy to be corrected.

For reference that is done in patch 03/11 of this series:
https://lore.kernel.org/lkml/20190821114955.12788-4-maennich@xxxxxxxxxx/

Cheers,
Matthias



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux