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 (diff)
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
next prev parent 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 \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.