menu "printk and dmesg options" config PRINTK_TIME	bool "Show timing information on printks"	depends on PRINTK	help	  Selecting this option causes time stamps of the printk()	  messages to be added to the output of the syslog() system	  call and at the console. 	  The timestamp is always recorded internally, and exported	  to /dev/kmsg. This flag just specifies if the timestamp should	  be included, not that the timestamp is recorded. 	  The behavior is also controlled by the kernel command line	  parameter printk.time=1. See Documentation/kernel-parameters.txt config MESSAGE_LOGLEVEL_DEFAULT	int "Default message log level (1-7)"	range 1 7	default "4"	help	  Default log level for printk statements with no specified priority. 	  This was hard-coded to KERN_WARNING since at least 2.6.10 but folks	  that are auditing their logs closely may want to set it to a lower	  priority. config BOOT_PRINTK_DELAY	bool "Delay each boot printk message by N milliseconds"	depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY	help	  This build option allows you to read kernel boot messages	  by inserting a short delay after each one.  The delay is	  specified in milliseconds on the kernel command line,	  using "boot_delay=N". 	  It is likely that you would also need to use "lpj=M" to preset	  the "loops per jiffie" value.	  See a previous boot log for the "lpj" value to use for your	  system, and then set "lpj=M" before setting "boot_delay=N".	  NOTE:  Using this option may adversely affect SMP systems.	  I.e., processors other than the first one may not boot up.	  BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect	  what it believes to be lockup conditions. config DYNAMIC_DEBUG	bool "Enable dynamic printk() support"	default n	depends on PRINTK	depends on DEBUG_FS	help 	  Compiles debug level messages into the kernel, which would not	  otherwise be available at runtime. These messages can then be	  enabled/disabled based on various levels of scope - per source file,	  function, module, format string, and line number. This mechanism	  implicitly compiles in all pr_debug() and dev_dbg() calls, which	  enlarges the kernel text size by about 2%. 	  If a source file is compiled with DEBUG flag set, any	  pr_debug() calls in it are enabled by default, but can be	  disabled at runtime as below.  Note that DEBUG flag is	  turned on by many CONFIG_*DEBUG* options. 	  Usage: 	  Dynamic debugging is controlled via the 'dynamic_debug/control' file,	  which is contained in the 'debugfs' filesystem. Thus, the debugfs	  filesystem must first be mounted before making use of this feature.	  We refer the control file as: <debugfs>/dynamic_debug/control. This	  file contains a list of the debug statements that can be enabled. The	  format for each line of the file is: 		filename:lineno [module]function flags format 	  filename : source file of the debug statement	  lineno : line number of the debug statement	  module : module that contains the debug statement	  function : function that contains the debug statement          flags : '=p' means the line is turned 'on' for printing          format : the format used for the debug statement 	  From a live system: 		nullarbor:~ # cat <debugfs>/dynamic_debug/control		# filename:lineno [module]function flags format		fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012"		fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012"		fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012" 	  Example usage: 		// enable the message at line 1603 of file svcsock.c		nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >						<debugfs>/dynamic_debug/control 		// enable all the messages in file svcsock.c		nullarbor:~ # echo -n 'file svcsock.c +p' >						<debugfs>/dynamic_debug/control 		// enable all the messages in the NFS server module		nullarbor:~ # echo -n 'module nfsd +p' >						<debugfs>/dynamic_debug/control 		// enable all 12 messages in the function svc_process()		nullarbor:~ # echo -n 'func svc_process +p' >						<debugfs>/dynamic_debug/control 		// disable all 12 messages in the function svc_process()		nullarbor:~ # echo -n 'func svc_process -p' >						<debugfs>/dynamic_debug/control 	  See Documentation/dynamic-debug-howto.txt for additional information. endmenu # "printk and dmesg options" menu "Compile-time checks and compiler options" config DEBUG_INFO	bool "Compile the kernel with debug info"	depends on DEBUG_KERNEL && !COMPILE_TEST	help          If you say Y here the resulting kernel image will include	  debugging info resulting in a larger kernel image.	  This adds debug symbols to the kernel and modules (gcc -g), and	  is needed if you intend to use kernel crashdump or binary object	  tools like crash, kgdb, LKCD, gdb, etc on the kernel.	  Say Y here only if you plan to debug the kernel. 	  If unsure, say N. config DEBUG_INFO_REDUCED	bool "Reduce debugging information"	depends on DEBUG_INFO	help	  If you say Y here gcc is instructed to generate less debugging	  information for structure types. This means that tools that	  need full debugging information (like kgdb or systemtap) won't	  be happy. But if you merely need debugging information to	  resolve line numbers there is no loss. Advantage is that	  build directory object sizes shrink dramatically over a full	  DEBUG_INFO build and compile times are reduced too.	  Only works with newer gcc versions. config DEBUG_INFO_SPLIT	bool "Produce split debuginfo in .dwo files"	depends on DEBUG_INFO	help	  Generate debug info into separate .dwo files. This significantly	  reduces the build directory size for builds with DEBUG_INFO,	  because it stores the information only once on disk in .dwo	  files instead of multiple times in object files and executables.	  In addition the debug information is also compressed. 	  Requires recent gcc (4.7+) and recent gdb/binutils.	  Any tool that packages or reads debug information would need	  to know about the .dwo files and include them.	  Incompatible with older versions of ccache. config DEBUG_INFO_DWARF4	bool "Generate dwarf4 debuginfo"	depends on DEBUG_INFO	help	  Generate dwarf4 debug info. This requires recent versions	  of gcc and gdb. It makes the debug information larger.	  But it significantly improves the success of resolving	  variables in gdb on optimized code. config GDB_SCRIPTS	bool "Provide GDB scripts for kernel debugging"	depends on DEBUG_INFO	help	  This creates the required links to GDB helper scripts in the	  build directory. If you load vmlinux into gdb, the helper	  scripts will be automatically imported by gdb as well, and	  additional functions are available to analyze a Linux kernel	  instance. See Documentation/gdb-kernel-debugging.txt for further	  details. config ENABLE_WARN_DEPRECATED	bool "Enable __deprecated logic"	default y	help	  Enable the __deprecated logic in the kernel build.	  Disable this to suppress the "warning: 'foo' is deprecated	  (declared at kernel/power/somefile.c:1234)" messages. config ENABLE_MUST_CHECK	bool "Enable __must_check logic"	default y	help	  Enable the __must_check logic in the kernel build.  Disable this to	  suppress the "warning: ignoring return value of 'foo', declared with	  attribute warn_unused_result" messages. config FRAME_WARN	int "Warn for stack frames larger than (needs gcc 4.4)"	range 0 8192	default 0 if KASAN	default 2048 if GCC_PLUGIN_LATENT_ENTROPY	default 1024 if !64BIT	default 2048 if 64BIT	help	  Tell gcc to warn at build time for stack frames larger than this.	  Setting this too low will cause a lot of warnings.	  Setting it to 0 disables the warning.	  Requires gcc 4.4 config STRIP_ASM_SYMS	bool "Strip assembler-generated symbols during link"	default n	help	  Strip internal assembler-generated symbols during a link (symbols	  that look like '.Lxxx') so they don't pollute the output of	  get_wchan() and suchlike. config READABLE_ASM        bool "Generate readable assembler code"        depends on DEBUG_KERNEL        help          Disable some compiler optimizations that tend to generate human unreadable          assembler output. This may make the kernel slightly slower, but it helps          to keep kernel developers who have to stare a lot at assembler listings          sane. 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 PAGE_OWNER	bool "Track page owner"	depends on DEBUG_KERNEL && STACKTRACE_SUPPORT	select DEBUG_FS	select STACKTRACE	select STACKDEPOT	select PAGE_EXTENSION	help	  This keeps track of what call chain is the owner of a page, may	  help to find bare alloc_page(s) leaks. Even if you include this	  feature on your build, it is disabled in default. You should pass	  "page_owner=on" to boot parameter in order to enable it. Eats	  a fair amount of memory if enabled. See tools/vm/page_owner_sort.c	  for user-space helper. 	  If unsure, say N. config DEBUG_FS	bool "Debug Filesystem"	select SRCU	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. 	  For detailed documentation on the debugfs API, see	  Documentation/DocBook/filesystems. 	  If unsure, say N. config HEADERS_CHECK	bool "Run 'make headers_check' when building vmlinux"	depends on !UML	help	  This option will extract the user-visible kernel headers whenever	  building the kernel, and will run basic sanity checks on them to	  ensure that exported files do not attempt to include files which	  were not exported, etc. 	  If you're making modifications to header files which are	  relevant for userspace, say 'Y', and check the headers	  exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in	  your build tree), to make sure they're suitable. config DEBUG_SECTION_MISMATCH	bool "Enable full Section mismatch analysis"	help	  The section mismatch analysis checks if there are illegal	  references from one section to another section.	  During linktime or runtime, some sections are dropped;	  any use of code/data previously in these sections would	  most likely result in an oops.	  In the code, functions and variables are annotated with	  __init,, etc. (see the full list in include/linux/init.h),	  which results in the code/data being placed in specific sections.	  The section mismatch analysis is always performed after a full	  kernel build, and enabling this option causes the following	  additional steps to occur:	  - Add the option -fno-inline-functions-called-once to gcc commands.	    When inlining a function annotated with __init in a non-init	    function, we would lose the section information and thus	    the analysis would not catch the illegal reference.	    This option tells gcc to inline less (but it does result in	    a larger kernel).	  - Run the section mismatch analysis for each module/built-in.o file.	    When we run the section mismatch analysis on vmlinux.o, we	    lose valuable information about where the mismatch was	    introduced.	    Running the analysis for each module/built-in.o file	    tells where the mismatch happens much closer to the	    source. The drawback is that the same mismatch is	    reported at least twice.	  - Enable verbose reporting from modpost in order to help resolve	    the section mismatches that are reported. config SECTION_MISMATCH_WARN_ONLY	bool "Make section mismatch errors non-fatal"	default y	help	  If you say N here, the build process will fail if there are any	  section mismatch, instead of just throwing warnings. 	  If unsure, say Y. ## Select this config option from the architecture Kconfig, if it# is preferred to always offer frame pointers as a config# option on the architecture (regardless of KERNEL_DEBUG):#config ARCH_WANT_FRAME_POINTERS	bool	help config FRAME_POINTER	bool "Compile the kernel with frame pointers"	depends on DEBUG_KERNEL && \		(CRIS || M68K || FRV || UML || \		 AVR32 || SUPERH || BLACKFIN || MN10300 || METAG) || \		ARCH_WANT_FRAME_POINTERS	default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS	help	  If you say Y here the resulting kernel image will be slightly	  larger and slower, but it gives very useful debugging information	  in case of kernel bugs. (precise oopses/stacktraces/warnings) config STACK_VALIDATION	bool "Compile-time stack metadata validation"	depends on HAVE_STACK_VALIDATION	default n	help	  Add compile-time checks to validate stack metadata, including frame	  pointers (if CONFIG_FRAME_POINTER is enabled).  This helps ensure	  that runtime stack traces are more reliable. 	  For more information, see	  tools/objtool/Documentation/stack-validation.txt. config DEBUG_FORCE_WEAK_PER_CPU	bool "Force weak per-cpu definitions"	depends on DEBUG_KERNEL	help	  s390 and alpha require percpu variables in modules to be	  defined weak to work around addressing range issue which	  puts the following two restrictions on percpu variable	  definitions. 	  1. percpu symbols must be unique whether static or not	  2. percpu variables can't be defined inside a function 	  To ensure that generic code follows the above rules, this	  option forces all percpu variables to be defined as weak. endmenu # "Compiler options" 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 MAGIC_SYSRQ_DEFAULT_ENABLE	hex "Enable magic SysRq key functions by default"	depends on MAGIC_SYSRQ	default 0x1	help	  Specifies which SysRq key functions are enabled by default.	  This may be set to 1 or 0 to enable or disable them all, or	  to a bitmask as described in Documentation/sysrq.txt. config DEBUG_KERNEL	bool "Kernel debugging"	help	  Say Y here if you are developing drivers or trying to debug and	  identify kernel problems. menu "Memory Debugging" source mm/Kconfig.debug config DEBUG_OBJECTS	bool "Debug object operations"	depends on DEBUG_KERNEL	help	  If you say Y here, additional code will be inserted into the	  kernel to track the life time of various objects and validate	  the operations on those objects. config DEBUG_OBJECTS_SELFTEST	bool "Debug objects selftest"	depends on DEBUG_OBJECTS	help	  This enables the selftest of the object debug code. config DEBUG_OBJECTS_FREE	bool "Debug objects in freed memory"	depends on DEBUG_OBJECTS	help	  This enables checks whether a k/v free operation frees an area	  which contains an object which has not been deactivated	  properly. This can make kmalloc/kfree-intensive workloads	  much slower. config DEBUG_OBJECTS_TIMERS	bool "Debug timer objects"	depends on DEBUG_OBJECTS	help	  If you say Y here, additional code will be inserted into the	  timer routines to track the life time of timer objects and	  validate the timer operations. config DEBUG_OBJECTS_WORK	bool "Debug work objects"	depends on DEBUG_OBJECTS	help	  If you say Y here, additional code will be inserted into the	  work queue routines to track the life time of work objects and	  validate the work operations. config DEBUG_OBJECTS_RCU_HEAD	bool "Debug RCU callbacks objects"	depends on DEBUG_OBJECTS	help	  Enable this to turn on debugging of RCU list heads (call_rcu() usage). config DEBUG_OBJECTS_PERCPU_COUNTER	bool "Debug percpu counter objects"	depends on DEBUG_OBJECTS	help	  If you say Y here, additional code will be inserted into the	  percpu counter routines to track the life time of percpu counter	  objects and validate the percpu counter operations. config DEBUG_OBJECTS_ENABLE_DEFAULT	int "debug_objects bootup default value (0-1)"        range 0 1        default "1"        depends on DEBUG_OBJECTS        help          Debug objects boot parameter default value config DEBUG_SLAB	bool "Debug slab memory allocations"	depends on DEBUG_KERNEL && SLAB && !KMEMCHECK	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 SLUB_DEBUG_ON	bool "SLUB debugging on by default"	depends on SLUB && SLUB_DEBUG && !KMEMCHECK	default n	help	  Boot with debugging on by default. SLUB boots by default with	  the runtime debug capabilities switched off. Enabling this is	  equivalent to specifying the "slub_debug" parameter on boot.	  There is no support for more fine grained debug control like	  possible with slub_debug=xxx. SLUB debugging may be switched	  off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying	  "slub_debug=-". config SLUB_STATS	default n	bool "Enable SLUB performance statistics"	depends on SLUB && SYSFS	help

Lines 1–500 of 2010. Load more