kevin/linux
1
Fork 0
Code
7a53cd16d4
linux/arch/sparc/Kconfig.debug

48 lines
1.1 KiB
Plaintext
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
menu "Kernel hacking"
[SPARC32]: Add irqflags.h to sparc32 and use it from generic code. Added asm-sparc/irqflags.h and moved irq related code from system.h to it. Renamed local_irq functions to raw_local_irq in irq.c. Modified system.h to include linux/irqflags.h which includes asm/irqflags.h. Added TRACE_IRQFLAGS_SUPPORT to Kconfig.debug. This is the first step in adding IRQ-flags state tracing as outlined in Documentation/irqflags-tracing.txt. These changes should be harmless because they just move things around and rename them. The next step is making the lowlevel entry code modifications which to be honest are beyond my capabilities at this point. Boot tested on an ss20 running an SMP kernel. Signed-off-by: Robert Reif <reif@earthlink.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-27 13:15:31 -07:00
config TRACE_IRQFLAGS_SUPPORT
bool
default y
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
source "lib/Kconfig.debug"
config DEBUG_STACK_USAGE
bool "Enable stack utilization instrumentation"
depends on DEBUG_KERNEL
help
Enables the display of the minimum amount of free stack which each
task has ever had available in the sysrq-T and sysrq-P debug output.
This option will slow down process creation somewhat.
sparc: unify Kconfig.debug Let sparc and sparc64 use the same Kconfig.debug Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-11-15 14:39:18 -07:00
config DEBUG_DCFLUSH
bool "D-cache flush debugging"
depends on SPARC64 && DEBUG_KERNEL
config MCOUNT
bool
depends on SPARC64
sparc64: Kill CONFIG_STACK_DEBUG code. The generic stack tracer does this job just as well. Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-12 22:36:03 -07:00
depends on FUNCTION_TRACER
sparc: unify Kconfig.debug Let sparc and sparc64 use the same Kconfig.debug Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2008-11-15 14:39:18 -07:00
default y
config FRAME_POINTER
bool
depends on MCOUNT
default y
sparc: Use __builtin_object_size() to validate the buffer size for copy_from_user() This mirrors x86 commit 9f0cf4adb6aa0bfccf675c938124e68f7f06349d (x86: Use __builtin_object_size() to validate the buffer size for copy_from_user()) Signed-off-by: David S. Miller <davem@davemloft.net>
2009-12-11 00:05:23 -07:00
config DEBUG_STRICT_USER_COPY_CHECKS
bool "Strict copy size checks"
depends on DEBUG_KERNEL && !TRACE_BRANCH_PROFILING
---help---
Enabling this option turns a certain set of sanity checks for user
copy operations into compile time failures.
The copy_from_user() etc checks are there to help test if there
are sufficient security checks on the length argument of
the copy operation, by having gcc prove that the argument is
within bounds.
If unsure, or if you run an older (pre 4.4) gcc, say N.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
endmenu
Copy Permalink