Re: [PATCH 04/10] module: make MODULE_SYMBOL_PREFIX into a CONFIG option

[Paul Mundt <lethal@linux-sh.org>]

On Tue, Nov 03, 2009 at 08:39:29AM -0500, Mike Frysinger wrote:
> On Tue, Nov 3, 2009 at 08:29, Paul Mundt wrote:
> > Having it in the Kconfig also makes it a nuisance for platforms that can
> > use -elf and -linux toolchains for the same tree for different platforms.
> > It would be nice to have this supported in such a way that we can just
> > set a flag from the Makefile and have a compiler test that determines
> > whether it is necessary or not.
> 
> what arch is this an issue for ?  the only symbol prefixed arches are
> Blackfin and H8300, and they dont provide toolchains that omit the
> prefix.
> 
No, those are the only symbol prefixed platforms enabled in the kernel at
present because neither one ships different toolchains.

The symbol prefixing itself is more an artifact of a -elf target
contrasted with a -linux one than anything "platform" specific. Thus, any
nommu platform using a bare metal or -elf toolchain can easily be used
for building the kernel if this can be supported in a clean way. As such,
a config option is not useful.

> trying to enable symbol prefix support dynamically based on the
> toolchain is a bad idea and pretty fragile.  the arch-specific
> assembly code would have to be all rewritten to wrap all C-visible
> symbols with a macro like VMLINUX_SYMBOL().
> 
There is nothing fragile about it, symbols are either prefixed or they
aren't. The common case for things like the syscall table obiously have
to be wrapped, but so what? C_SYMBOL_PREFIX() used to be the norm back in
the day, so it obiously worked well enough for the common case.

> i say let anyone who actually has such a system and wants to do such a
> crazy ass thing put together a working arch first before we worry
> about it.  the current code doesnt preclude dynamic hooking anyways
> (manually adding -DCONFIG_xxx to CPPFLAGS).

You talk about fragile bad ideas and then throw out defining Kconfig
variables from Makefiles? This simply has no place in the Kconfig space,
as it is now and always has been a toolchain property, not an
architectural/platform one.

The other thing you seem to have ignored is that pretty much everyone has
such a system, it's only crippled platforms like blackfin and h8300 that
don't support toolchains without the prefix.