⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 kconfig.debug

📁 Lib files of linux kernel
💻 DEBUG
📖 第 1 页 / 共 2 页
字号:
	 If a deadlock is impossible (i.e. the locking rules, as	 observed by the kernel, are mathematically correct), the	 kernel reports nothing.	 NOTE: this feature can also be enabled for rwlocks, mutexes	 and rwsems - in which case all dependencies between these	 different locking variants are observed and mapped too, and	 the proof of observed correctness is also maintained for an	 arbitrary combination of these separate locking variants.	 For more details, see Documentation/lockdep-design.txt.config LOCKDEP	bool	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT	select STACKTRACE	select FRAME_POINTER if !X86 && !MIPS && !PPC	select KALLSYMS	select KALLSYMS_ALLconfig LOCK_STAT	bool "Lock usage statistics"	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT	select LOCKDEP	select DEBUG_SPINLOCK	select DEBUG_MUTEXES	select DEBUG_LOCK_ALLOC	default n	help	 This feature enables tracking lock contention points	 For more details, see Documentation/lockstat.txtconfig DEBUG_LOCKDEP	bool "Lock dependency engine debugging"	depends on DEBUG_KERNEL && LOCKDEP	help	  If you say Y here, the lock dependency engine will do	  additional runtime checks to debug itself, at the price	  of more runtime overhead.config TRACE_IRQFLAGS	depends on DEBUG_KERNEL	bool	default y	depends on TRACE_IRQFLAGS_SUPPORT	depends on PROVE_LOCKINGconfig DEBUG_SPINLOCK_SLEEP	bool "Spinlock debugging: 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_LOCKING_API_SELFTESTS	bool "Locking API boot-time self-tests"	depends on DEBUG_KERNEL	help	  Say Y here if you want the kernel to run a short self-test during	  bootup. The self-test checks whether common types of locking bugs	  are detected by debugging mechanisms or not. (if you disable	  lock debugging then those bugs wont be detected of course.)	  The following locking APIs are covered: spinlocks, rwlocks,	  mutexes and rwsems.config STACKTRACE	bool	depends on STACKTRACE_SUPPORTconfig 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 || AVR32 || M32R || M68K || SPARC32 || SPARC64 || \		   FRV || SUPERH || GENERIC_BUG || BLACKFIN || MN10300	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.	  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_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 DEBUG_WRITECOUNT	bool "Debug filesystem writers count"	depends on DEBUG_KERNEL	help	  Enable this to catch wrong use of the writers count in struct	  vfsmount.  This will increase the size of each file struct by	  32 bits.	  If unsure, say N.config DEBUG_MEMORY_INIT	bool "Debug memory initialisation" if EMBEDDED	default !EMBEDDED	help	  Enable this for additional checks during memory initialisation.	  The sanity checks verify aspects of the VM such as the memory model	  and other information provided by the architecture. Verbose	  information will be printed at KERN_DEBUG loglevel depending	  on the mminit_loglevel= command-line option.	  If unsure, say Yconfig DEBUG_LIST	bool "Debug linked list manipulation"	depends on DEBUG_KERNEL	help	  Enable this to turn on extended checks in the linked-list	  walking routines.	  If unsure, say N.config DEBUG_SG	bool "Debug SG table operations"	depends on DEBUG_KERNEL	help	  Enable this to turn on checks on scatter-gather tables. This can	  help find problems with drivers that do not properly initialize	  their sg tables.	  If unsure, say N.config FRAME_POINTER	bool "Compile the kernel with frame pointers"	depends on DEBUG_KERNEL && \		(X86 || CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \		 AVR32 || SUPERH || BLACKFIN || MN10300)	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 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 DETECT_SOFTLOCKUP to detect	  what it believes to be lockup conditions.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 be built into	  the kernel.	  Say M if you want the RCU torture tests to build as a module.	  Say N if you are unsure.config RCU_TORTURE_TEST_RUNNABLE	bool "torture tests for RCU runnable by default"	depends on RCU_TORTURE_TEST = y	default n	help	  This option provides a way to build the RCU torture tests	  directly into the kernel without them starting up at boot	  time.  You can use /proc/sys/kernel/rcutorture_runnable	  to manually override this setting.  This /proc file is	  available only when the RCU torture tests have been built	  into the kernel.	  Say Y here if you want the RCU torture tests to start during	  boot (you probably don't).	  Say N here if you want the RCU torture tests to start only	  after being manually enabled via /proc.config KPROBES_SANITY_TEST	bool "Kprobes sanity tests"	depends on DEBUG_KERNEL	depends on KPROBES	default n	help	  This option provides for testing basic kprobes functionality on	  boot. A sample kprobe, jprobe and kretprobe are inserted and	  verified for functionality.	  Say N if you are unsure.config BACKTRACE_SELF_TEST	tristate "Self test for the backtrace code"	depends on DEBUG_KERNEL	default n	help	  This option provides a kernel module that can be used to test	  the kernel stack backtrace code. This option is not useful	  for distributions or general kernels, but only for kernel	  developers working on architecture code.	  Note that if you want to also test saved backtraces, you will	  have to enable STACKTRACE as well.	  Say N if you are unsure.config LKDTM	tristate "Linux Kernel Dump Test Tool Module"	depends on DEBUG_KERNEL	depends on KPROBES	depends on BLOCK	default n	help	This module enables testing of the different dumping mechanisms by	inducing system failures at predefined crash points.	If you don't need it: say N	Choose M here to compile this code as a module. The module will be	called lkdtm.	Documentation on how to use the module can be found in	drivers/misc/lkdtm.cconfig FAULT_INJECTION	bool "Fault-injection framework"	depends on DEBUG_KERNEL	help	  Provide fault-injection framework.	  For more details, see Documentation/fault-injection/.config FAILSLAB	bool "Fault-injection capability for kmalloc"	depends on FAULT_INJECTION	help	  Provide fault-injection capability for kmalloc.config FAIL_PAGE_ALLOC	bool "Fault-injection capabilitiy for alloc_pages()"	depends on FAULT_INJECTION	help	  Provide fault-injection capability for alloc_pages().config FAIL_MAKE_REQUEST	bool "Fault-injection capability for disk IO"	depends on FAULT_INJECTION	help	  Provide fault-injection capability for disk IO.config FAULT_INJECTION_DEBUG_FS	bool "Debugfs entries for fault-injection capabilities"	depends on FAULT_INJECTION && SYSFS && DEBUG_FS	help	  Enable configuration of fault-injection capabilities via debugfs.config FAULT_INJECTION_STACKTRACE_FILTER	bool "stacktrace filter for fault-injection capabilities"	depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT	depends on !X86_64	select STACKTRACE	select FRAME_POINTER if !PPC	help	  Provide stacktrace filter for fault-injection capabilitiesconfig LATENCYTOP	bool "Latency measuring infrastructure"	select FRAME_POINTER if !MIPS && !PPC	select KALLSYMS	select KALLSYMS_ALL	select STACKTRACE	select SCHEDSTATS	select SCHED_DEBUG	depends on HAVE_LATENCYTOP_SUPPORT	help	  Enable this option if you want to use the LatencyTOP tool	  to find out which userspace is blocking on what kernel operations.config SYSCTL_SYSCALL_CHECK	bool "Sysctl checks"	depends on SYSCTL_SYSCALL	---help---	  sys_sysctl uses binary paths that have been found challenging	  to properly maintain and use. This enables checks that help	  you to keep things correct.source kernel/trace/Kconfigconfig PROVIDE_OHCI1394_DMA_INIT	bool "Remote debugging over FireWire early on boot"	depends on PCI && X86	help	  If you want to debug problems which hang or crash the kernel early	  on boot and the crashing machine has a FireWire port, you can use	  this feature to remotely access the memory of the crashed machine	  over FireWire. This employs remote DMA as part of the OHCI1394	  specification which is now the standard for FireWire controllers.	  With remote DMA, you can monitor the printk buffer remotely using	  firescope and access all memory below 4GB using fireproxy from gdb.	  Even controlling a kernel debugger is possible using remote DMA.	  Usage:	  If ohci1394_dma=early is used as boot parameter, it will initialize	  all OHCI1394 controllers which are found in the PCI config space.	  As all changes to the FireWire bus such as enabling and disabling	  devices cause a bus reset and thereby disable remote DMA for all	  devices, be sure to have the cable plugged and FireWire enabled on	  the debugging host before booting the debug target for debugging.	  This code (~1k) is freed after boot. By then, the firewire stack	  in charge of the OHCI-1394 controllers should be used instead.	  See Documentation/debugging-via-ohci1394.txt for more information.config FIREWIRE_OHCI_REMOTE_DMA	bool "Remote debugging over FireWire with firewire-ohci"	depends on FIREWIRE_OHCI	help	  This option lets you use the FireWire bus for remote debugging	  with help of the firewire-ohci driver. It enables unfiltered	  remote DMA in firewire-ohci.	  See Documentation/debugging-via-ohci1394.txt for more information.	  If unsure, say N.menuconfig BUILD_DOCSRC	bool "Build targets in Documentation/ tree"	depends on HEADERS_CHECK	help	  This option attempts to build objects from the source files in the	  kernel Documentation/ tree.	  Say N if you are unsure.source "samples/Kconfig"source "lib/Kconfig.kgdb"

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -