All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier.adi@gmail.com>
To: Paul Mundt <lethal@linux-sh.org>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>,
	greg@kroah.com, linux-kbuild@vger.kernel.org,
	carmelo73@gmail.com, linux-kernel@vger.kernel.org,
	rusty@rustcorp.com.au
Subject: Re: [PATCH 04/10] module: make MODULE_SYMBOL_PREFIX into a CONFIG  option
Date: Tue, 3 Nov 2009 08:58:49 -0500	[thread overview]
Message-ID: <8bd0f97a0911030558h58725a95m31bb2f73c0772547@mail.gmail.com> (raw)
In-Reply-To: <20091103134652.GB12841@linux-sh.org>

On Tue, Nov 3, 2009 at 08:46, Paul Mundt wrote:
> 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.

and most likely never will.  the Blackfin symbol prefix is every
where, userspace included.

> 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.

which has no bearing on the Blackfin case as every toolchain target
can currently be used to build the kernel

>> 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.

it worked well when it was the *common* case as you said.  when people
rarely use it (which is what happens today), things constantly break
because no one tests it, the usage is awkward, and it's an artifact
that shouldnt exist in the first place.

>> 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.

my point was that it can easily be mixed.  i personally could care
less where the symbol is declared so long as it's declared just once.

> 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.

"cripple" is exactly the right word.  why in the world do you want to
cripple people that dont need it ?  attempting to support busted
toolchains by forcing even more symbol prefix crap throughout an arch
makes no sense at all.  use the -fno-leading-underscore gcc option if
you want to re-use a non-standard symbol prefixed elf compiler to
build an arch.
-mike

WARNING: multiple messages have this Message-ID
From: Mike Frysinger <vapier.adi@gmail.com>
To: Paul Mundt <lethal@linux-sh.org>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>,
	greg@kroah.com, linux-kbuild@vger.kernel.org,
	carmelo73@gmail.com, linux-kernel@vger.kernel.org,
	rusty@rustcorp.com.au
Subject: Re: [PATCH 04/10] module: make MODULE_SYMBOL_PREFIX into a CONFIG option
Date: Tue, 3 Nov 2009 08:58:49 -0500	[thread overview]
Message-ID: <8bd0f97a0911030558h58725a95m31bb2f73c0772547@mail.gmail.com> (raw)
In-Reply-To: <20091103134652.GB12841@linux-sh.org>

On Tue, Nov 3, 2009 at 08:46, Paul Mundt wrote:
> 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.

and most likely never will.  the Blackfin symbol prefix is every
where, userspace included.

> 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.

which has no bearing on the Blackfin case as every toolchain target
can currently be used to build the kernel

>> 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.

it worked well when it was the *common* case as you said.  when people
rarely use it (which is what happens today), things constantly break
because no one tests it, the usage is awkward, and it's an artifact
that shouldnt exist in the first place.

>> 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.

my point was that it can easily be mixed.  i personally could care
less where the symbol is declared so long as it's declared just once.

> 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.

"cripple" is exactly the right word.  why in the world do you want to
cripple people that dont need it ?  attempting to support busted
toolchains by forcing even more symbol prefix crap throughout an arch
makes no sense at all.  use the -fno-leading-underscore gcc option if
you want to re-use a non-standard symbol prefixed elf compiler to
build an arch.
-mike

  reply	other threads:[~2009-11-03 13:59 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-02 16:52 Fast LKM symbol resolution Alan Jenkins
2009-11-03  3:55 ` Greg KH
2009-11-03 10:06 ` [PATCH 0/10] module: Speed up symbol resolution during module loading (using binary search) Alan Jenkins
2009-11-03 15:58   ` Greg KH
2009-11-05 12:17     ` Rusty Russell
2009-11-03 10:06 ` [PATCH 01/10] ARM: use unified discard definition in linker script Alan Jenkins
2009-11-03 10:06 ` [PATCH 02/10] ARM: unexport symbols used to implement floating point emulation Alan Jenkins
2009-11-03 10:06 ` [PATCH 03/10] module: extract __EXPORT_SYMBOL from module.h into mod_export.h Alan Jenkins
2009-11-03 10:06 ` [PATCH 04/10] module: make MODULE_SYMBOL_PREFIX into a CONFIG option Alan Jenkins
2009-11-03 10:19   ` Mike Frysinger
2009-11-03 10:19     ` Mike Frysinger
2009-11-03 12:16     ` Alan Jenkins
2009-11-03 12:30       ` Mike Frysinger
2009-11-03 12:30         ` Mike Frysinger
2009-11-03 13:29         ` Paul Mundt
2009-11-03 13:39           ` Mike Frysinger
2009-11-03 13:39             ` Mike Frysinger
2009-11-03 13:46             ` Paul Mundt
2009-11-03 13:58               ` Mike Frysinger [this message]
2009-11-03 13:58                 ` Mike Frysinger
2009-11-03 14:07                 ` Paul Mundt
2009-11-03 10:06 ` [PATCH 05/10] kbuild: sort the list of symbols exported by the kernel (__ksymtab) Alan Jenkins
2009-11-04  8:19   ` Rusty Russell
2009-11-04 10:00     ` Alan Jenkins
2009-11-04 11:12       ` Mike Frysinger
2009-11-04 11:12         ` Mike Frysinger
2009-11-04 17:19       ` Sam Ravnborg
2009-11-05 14:24         ` Alan Jenkins
2009-11-05 16:17           ` Mike Frysinger
2009-11-05 16:17             ` Mike Frysinger
2009-11-09  3:17           ` Rusty Russell
2009-11-20 22:20             ` Tony Luck
2009-11-20 22:20               ` Tony Luck
2009-11-21  0:02               ` Alan Jenkins
2009-11-23 19:53                 ` Alex Chiang
2009-11-23 22:44                   ` Alan Jenkins
2009-11-24  0:57                   ` Rusty Russell
2009-11-24  5:39                     ` James Bottomley
2009-11-24  9:28                       ` Alan Jenkins
2009-11-24 22:43                         ` James Bottomley
2009-11-25  9:15                           ` Alan Jenkins
2009-11-25 15:08                             ` James Bottomley
2009-11-25 17:01                               ` Alan Jenkins
2009-11-27 11:03                               ` Rusty Russell
2009-11-26  0:40   ` Andrew Morton
2009-11-26 17:14     ` Alan Jenkins
2009-11-03 10:06 ` [PATCH 06/10] module: refactor symbol tables and try to reduce code size of each_symbol() Alan Jenkins
2009-11-04  8:28   ` Rusty Russell
2009-11-04  9:45     ` Alan Jenkins
2009-11-03 10:06 ` [PATCH 07/10] lib: Add generic binary search function to the kernel Alan Jenkins
2009-11-03 10:06 ` [PATCH 08/10] lib: bsearch - remove redundant special case for arrays of size 0 Alan Jenkins
2009-11-03 10:06 ` [PATCH 09/10] module: speed up find_symbol() using binary search on the builtin symbol tables Alan Jenkins
2009-11-04  8:31   ` Rusty Russell
2009-11-03 10:06 ` [PATCH 10/10] module: fix is_exported() to return true for all types of exports Alan Jenkins
2009-11-04  8:32   ` Rusty Russell
2009-11-06  5:37 ` Fast LKM symbol resolution Carmelo Amoroso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8bd0f97a0911030558h58725a95m31bb2f73c0772547@mail.gmail.com \
    --to=vapier.adi@gmail.com \
    --cc=alan-jenkins@tuffmail.co.uk \
    --cc=carmelo73@gmail.com \
    --cc=greg@kroah.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --subject='Re: [PATCH 04/10] module: make MODULE_SYMBOL_PREFIX into a CONFIG  option' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.