lib/Kconfig.debug
Source file repositories/reference/linux-study-clean/lib/Kconfig.debug
File Facts
- System
- Linux kernel
- Corpus path
lib/Kconfig.debug- Extension
.debug- Size
- 121805 bytes
- Lines
- 3646
- Domain
- Kernel Services
- Bucket
- lib
- Inferred role
- Kernel Services: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Shared kernel service surface used by multiple subsystems, including helpers, cryptography, virtualization support, and async I/O infrastructure.
- Shared kernel service surface used by multiple subsystems, including helpers, cryptography, virtualization support, and async I/O infrastructure.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Touches user memory; correctness depends on fault-safe copying and privilege boundary handling.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
# SPDX-License-Identifier: GPL-2.0-only
menu "Kernel hacking"
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/admin-guide/kernel-parameters.rst
config PRINTK_CALLER
bool "Show caller information on printks"
depends on PRINTK
help
Selecting this option causes printk() to add a caller "thread id" (if
in task context) or a caller "processor id" (if not in task context)
to every message.
This option is intended for environments where multiple threads
concurrently call printk() for many times, for it is difficult to
interpret without knowing where these lines (or sometimes individual
line which was divided into multiple lines due to race) came from.
Since toggling after boot makes the code racy, currently there is
no option to enable/disable at the kernel command line parameter or
sysfs interface.
config PRINTK_EXECUTION_CTX
bool
depends on PRINTK
help
This option extends struct printk_info to include extra execution
context in printk, such as task name and CPU number from where the
message originated. This is useful for correlating printk messages
with specific execution contexts.
This is automatically enabled when a console driver that supports
execution context is selected.
config STACKTRACE_BUILD_ID
bool "Show build ID information in stacktraces"
depends on PRINTK
help
Selecting this option adds build ID information for symbols in
stacktraces printed with the printk format '%p[SR]b'.
This option is intended for distros where debuginfo is not easily
accessible but can be downloaded given the build ID of the vmlinux or
kernel module where the function is located.
config CONSOLE_LOGLEVEL_DEFAULT
int "Default console loglevel (1-15)"
range 1 15
default "7"
help
Default loglevel to determine what will be printed on the console.
Setting a default here is equivalent to passing in loglevel=<x> in
the kernel bootargs. loglevel=<x> continues to override whatever
value is specified here as well.
Annotation
- Atlas domain: Kernel Services / lib.
- Implementation status: integration implementation candidate.
- This snippet crosses the user/kernel memory boundary; validate fault handling and access checks before translating the pattern.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.