This config option isn't actually used anywhere and can be safely
removed. The last user was traps.c before commit 082f47a ([ARM]
always allow dump_stack() to produce a backtrace, 2007-07-05).
Signed-off-by: Stephen Boyd <[email protected]>
---
arch/arm/Kconfig.debug | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 494224a..03d01d7 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -63,17 +63,6 @@ config DEBUG_USER
8 - SIGSEGV faults
16 - SIGBUS faults
-config DEBUG_ERRORS
- bool "Verbose kernel error messages"
- depends on DEBUG_KERNEL
- help
- This option controls verbose debugging information which can be
- printed when the kernel detects an internal error. This debugging
- information is useful to kernel hackers when tracking down problems,
- but mostly meaningless to other people. It's safe to say Y unless
- you are concerned with the code size or don't want to see these
- messages.
-
config DEBUG_STACK_USAGE
bool "Enable stack utilization instrumentation"
depends on DEBUG_KERNEL
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Fri, 8 Apr 2011, Stephen Boyd wrote:
> This config option isn't actually used anywhere and can be safely
> removed. The last user was traps.c before commit 082f47a ([ARM]
> always allow dump_stack() to produce a backtrace, 2007-07-05).
>
> Signed-off-by: Stephen Boyd <[email protected]>
Ok, this patch looks sane, so feel free to add :
Reviewed-by: Jesper Juhl <[email protected]>
But, I see a lot of *_defconfig files in my copy of the tree that
reference the option :
./arch/arm/configs/realview_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/ixp2000_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/netx_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/em_x270_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/tct_hammer_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/integrator_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/s3c6400_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/s5p6442_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/jornada720_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/imote2_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/mmp2_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/hackkit_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/lpd270_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/u8500_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/s5pc100_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/cerfcube_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/cm_x2xx_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/exynos4_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/simpad_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/colibri_pxa270_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/kirkwood_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/realview-smp_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/magician_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/mv78xx0_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/s5pv210_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/ns9xxx_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/corgi_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/ixp4xx_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/vexpress_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/pxa168_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/orion5x_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/pxa910_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/omap1_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/spitz_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/viper_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/pxa255-idp_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/colibri_pxa300_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/neponset_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/lubbock_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/collie_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/dove_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/rpc_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/mainstone_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/badge4_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/raumfeld_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/s5p64x0_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/ixp23xx_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/versatile_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/ezx_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/davinci_all_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/da8xx_omapl_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/zeus_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/s3c2410_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/am200epdkit_defconfig:CONFIG_DEBUG_ERRORS=y
./arch/arm/configs/ep93xx_defconfig:CONFIG_DEBUG_ERRORS=y
shouldn't those lines be removed as well?
I can submit a patch, but I thought you'd rather do it yourself..
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
> But, I see a lot of *_defconfig files in my copy of the tree that
> reference the option :
>
[snip]
> shouldn't those lines be removed as well?
>
> I can submit a patch, but I thought you'd rather do it yourself..
>
I was concerned that it would be more churn in the defconfigs. I can
make a patch for that too though. Or we could just wait for the
defconfigs to be regenerated and then the symbols would be dropped?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Mon, Apr 11, 2011 at 10:15:12AM -0700, Stephen Boyd wrote:
> > But, I see a lot of *_defconfig files in my copy of the tree that
> > reference the option :
> >
> [snip]
> > shouldn't those lines be removed as well?
> >
> > I can submit a patch, but I thought you'd rather do it yourself..
> >
>
> I was concerned that it would be more churn in the defconfigs. I can
> make a patch for that too though. Or we could just wait for the
> defconfigs to be regenerated and then the symbols would be dropped?
Two points here:
1. if it removes stuff, that's good.
2. but it has the potential to cause conflicts when other defconfig
updates happen.
I think (2) outweighs (1), and as it's only one line, I agree with the
idea of just leaving it for when the defconfigs get updated. We need
more effort spent on consolidating the bigger fish...