f71d20e961
Temporarily add EXPORT_UNUSED_SYMBOL and EXPORT_UNUSED_SYMBOL_GPL. These will be used as a transition measure for symbols that aren't used in the kernel and are on the way out. When a module uses such a symbol, a warning is printk'd at modprobe time. The main reason for removing unused exports is size: eacho export takes roughly between 100 and 150 bytes of kernel space in the binary. This patch gives users the option to immediately get this size gain via a config option. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
267 lines
9.1 KiB
Text
267 lines
9.1 KiB
Text
|
|
config PRINTK_TIME
|
|
bool "Show timing information on printks"
|
|
help
|
|
Selecting this option causes timing information to be
|
|
included in printk output. This allows you to measure
|
|
the interval between kernel operations, including bootup
|
|
operations. This is useful for identifying long delays
|
|
in kernel startup.
|
|
|
|
|
|
config MAGIC_SYSRQ
|
|
bool "Magic SysRq key"
|
|
depends on !UML
|
|
help
|
|
If you say Y here, you will have some control over the system even
|
|
if the system crashes for example during kernel debugging (e.g., you
|
|
will be able to flush the buffer cache to disk, reboot the system
|
|
immediately or dump some status information). This is accomplished
|
|
by pressing various keys while holding SysRq (Alt+PrintScreen). It
|
|
also works on a serial console (on PC hardware at least), if you
|
|
send a BREAK and then within 5 seconds a command keypress. The
|
|
keys are documented in <file:Documentation/sysrq.txt>. Don't say Y
|
|
unless you really know what this hack does.
|
|
|
|
config UNUSED_SYMBOLS
|
|
bool "Enable unused/obsolete exported symbols"
|
|
default y if X86
|
|
help
|
|
Unused but exported symbols make the kernel needlessly bigger. For
|
|
that reason most of these unused exports will soon be removed. This
|
|
option is provided temporarily to provide a transition period in case
|
|
some external kernel module needs one of these symbols anyway. If you
|
|
encounter such a case in your module, consider if you are actually
|
|
using the right API. (rationale: since nobody in the kernel is using
|
|
this in a module, there is a pretty good chance it's actually the
|
|
wrong interface to use). If you really need the symbol, please send a
|
|
mail to the linux kernel mailing list mentioning the symbol and why
|
|
you really need it, and what the merge plan to the mainline kernel for
|
|
your module is.
|
|
|
|
config DEBUG_KERNEL
|
|
bool "Kernel debugging"
|
|
help
|
|
Say Y here if you are developing drivers or trying to debug and
|
|
identify kernel problems.
|
|
|
|
config LOG_BUF_SHIFT
|
|
int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" if DEBUG_KERNEL
|
|
range 12 21
|
|
default 17 if S390
|
|
default 16 if X86_NUMAQ || IA64
|
|
default 15 if SMP
|
|
default 14
|
|
help
|
|
Select kernel log buffer size as a power of 2.
|
|
Defaults and Examples:
|
|
17 => 128 KB for S/390
|
|
16 => 64 KB for x86 NUMAQ or IA-64
|
|
15 => 32 KB for SMP
|
|
14 => 16 KB for uniprocessor
|
|
13 => 8 KB
|
|
12 => 4 KB
|
|
|
|
config DETECT_SOFTLOCKUP
|
|
bool "Detect Soft Lockups"
|
|
depends on DEBUG_KERNEL
|
|
default y
|
|
help
|
|
Say Y here to enable the kernel to detect "soft lockups",
|
|
which are bugs that cause the kernel to loop in kernel
|
|
mode for more than 10 seconds, without giving other tasks a
|
|
chance to run.
|
|
|
|
When a soft-lockup is detected, the kernel will print the
|
|
current stack trace (which you should report), but the
|
|
system will stay locked up. This feature has negligible
|
|
overhead.
|
|
|
|
(Note that "hard lockups" are separate type of bugs that
|
|
can be detected via the NMI-watchdog, on platforms that
|
|
support it.)
|
|
|
|
config SCHEDSTATS
|
|
bool "Collect scheduler statistics"
|
|
depends on DEBUG_KERNEL && PROC_FS
|
|
help
|
|
If you say Y here, additional code will be inserted into the
|
|
scheduler and related routines to collect statistics about
|
|
scheduler behavior and provide them in /proc/schedstat. These
|
|
stats may be useful for both tuning and debugging the scheduler
|
|
If you aren't debugging the scheduler or trying to tune a specific
|
|
application, you can say N to avoid the very slight overhead
|
|
this adds.
|
|
|
|
config DEBUG_SLAB
|
|
bool "Debug slab memory allocations"
|
|
depends on DEBUG_KERNEL && SLAB
|
|
help
|
|
Say Y here to have the kernel do limited verification on memory
|
|
allocation as well as poisoning memory on free to catch use of freed
|
|
memory. This can make kmalloc/kfree-intensive workloads much slower.
|
|
|
|
config DEBUG_SLAB_LEAK
|
|
bool "Memory leak debugging"
|
|
depends on DEBUG_SLAB
|
|
|
|
config DEBUG_PREEMPT
|
|
bool "Debug preemptible kernel"
|
|
depends on DEBUG_KERNEL && PREEMPT
|
|
default y
|
|
help
|
|
If you say Y here then the kernel will use a debug variant of the
|
|
commonly used smp_processor_id() function and will print warnings
|
|
if kernel code uses it in a preemption-unsafe way. Also, the kernel
|
|
will detect preemption count underflows.
|
|
|
|
config DEBUG_MUTEXES
|
|
bool "Mutex debugging, deadlock detection"
|
|
default n
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
This allows mutex semantics violations and mutex related deadlocks
|
|
(lockups) to be detected and reported automatically.
|
|
|
|
config DEBUG_RT_MUTEXES
|
|
bool "RT Mutex debugging, deadlock detection"
|
|
depends on DEBUG_KERNEL && RT_MUTEXES
|
|
help
|
|
This allows rt mutex semantics violations and rt mutex related
|
|
deadlocks (lockups) to be detected and reported automatically.
|
|
|
|
config DEBUG_PI_LIST
|
|
bool
|
|
default y
|
|
depends on DEBUG_RT_MUTEXES
|
|
|
|
config RT_MUTEX_TESTER
|
|
bool "Built-in scriptable tester for rt-mutexes"
|
|
depends on DEBUG_KERNEL && RT_MUTEXES
|
|
help
|
|
This option enables a rt-mutex tester.
|
|
|
|
config DEBUG_SPINLOCK
|
|
bool "Spinlock debugging"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
Say Y here and build SMP to catch missing spinlock initialization
|
|
and certain other kinds of spinlock errors commonly made. This is
|
|
best used in conjunction with the NMI watchdog so that spinlock
|
|
deadlocks are also debuggable.
|
|
|
|
config DEBUG_SPINLOCK_SLEEP
|
|
bool "Sleep-inside-spinlock checking"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
If you say Y here, various routines which may sleep will become very
|
|
noisy if they are called with a spinlock held.
|
|
|
|
config DEBUG_KOBJECT
|
|
bool "kobject debugging"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
If you say Y here, some extra kobject debugging messages will be sent
|
|
to the syslog.
|
|
|
|
config DEBUG_HIGHMEM
|
|
bool "Highmem debugging"
|
|
depends on DEBUG_KERNEL && HIGHMEM
|
|
help
|
|
This options enables addition error checking for high memory systems.
|
|
Disable for production systems.
|
|
|
|
config DEBUG_BUGVERBOSE
|
|
bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED
|
|
depends on BUG
|
|
depends on ARM || ARM26 || M32R || M68K || SPARC32 || SPARC64 || X86_32 || FRV
|
|
default !EMBEDDED
|
|
help
|
|
Say Y here to make BUG() panics output the file name and line number
|
|
of the BUG call as well as the EIP and oops trace. This aids
|
|
debugging but costs about 70-100K of memory.
|
|
|
|
config DEBUG_INFO
|
|
bool "Compile the kernel with debug info"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
If you say Y here the resulting kernel image will include
|
|
debugging info resulting in a larger kernel image.
|
|
Say Y here only if you plan to debug the kernel.
|
|
|
|
If unsure, say N.
|
|
|
|
config DEBUG_FS
|
|
bool "Debug Filesystem"
|
|
depends on SYSFS
|
|
help
|
|
debugfs is a virtual file system that kernel developers use to put
|
|
debugging files into. Enable this option to be able to read and
|
|
write to these files.
|
|
|
|
If unsure, say N.
|
|
|
|
config DEBUG_VM
|
|
bool "Debug VM"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
Enable this to turn on extended checks in the virtual-memory system
|
|
that may impact performance.
|
|
|
|
If unsure, say N.
|
|
|
|
config FRAME_POINTER
|
|
bool "Compile the kernel with frame pointers"
|
|
depends on DEBUG_KERNEL && (X86 || CRIS || M68K || M68KNOMMU || FRV || UML)
|
|
default y if DEBUG_INFO && UML
|
|
help
|
|
If you say Y here the resulting kernel image will be slightly larger
|
|
and slower, but it might give very useful debugging information on
|
|
some architectures or if you use external debuggers.
|
|
If you don't debug the kernel, you can say N.
|
|
|
|
config UNWIND_INFO
|
|
bool "Compile the kernel with frame unwind information"
|
|
depends on !IA64 && !PARISC
|
|
depends on !MODULES || !(MIPS || PPC || SUPERH || V850)
|
|
help
|
|
If you say Y here the resulting kernel image will be slightly larger
|
|
but not slower, and it will give very useful debugging information.
|
|
If you don't debug the kernel, you can say N, but we may not be able
|
|
to solve problems without frame unwind information or frame pointers.
|
|
|
|
config STACK_UNWIND
|
|
bool "Stack unwind support"
|
|
depends on UNWIND_INFO
|
|
depends on X86
|
|
help
|
|
This enables more precise stack traces, omitting all unrelated
|
|
occurrences of pointers into kernel code from the dump.
|
|
|
|
config FORCED_INLINING
|
|
bool "Force gcc to inline functions marked 'inline'"
|
|
depends on DEBUG_KERNEL
|
|
default y
|
|
help
|
|
This option determines if the kernel forces gcc to inline the functions
|
|
developers have marked 'inline'. Doing so takes away freedom from gcc to
|
|
do what it thinks is best, which is desirable for the gcc 3.x series of
|
|
compilers. The gcc 4.x series have a rewritten inlining algorithm and
|
|
disabling this option will generate a smaller kernel there. Hopefully
|
|
this algorithm is so good that allowing gcc4 to make the decision can
|
|
become the default in the future, until then this option is there to
|
|
test gcc for this.
|
|
|
|
config RCU_TORTURE_TEST
|
|
tristate "torture tests for RCU"
|
|
depends on DEBUG_KERNEL
|
|
default n
|
|
help
|
|
This option provides a kernel module that runs torture tests
|
|
on the RCU infrastructure. The kernel module may be built
|
|
after the fact on the running kernel to be tested, if desired.
|
|
|
|
Say Y here if you want RCU torture tests to start automatically
|
|
at boot time (you probably don't).
|
|
Say M if you want the RCU torture tests to build as a module.
|
|
Say N if you are unsure.
|