📷 Suggested Image for This Post

Use a screenshot of make menuconfig running in a Linux terminal showing the Kernel Hacking menu. Annotate with arrows pointing to a bool option [*] and a tristate option <M>. Alt text: “Linux kernel menuconfig interface showing bool and tristate Kconfig options — free linux kernel development course”. This kind of real terminal screenshot builds trust and ranks well for image search on linux kernel configuration keywords.

📁 Where Do Kconfig Files Live in the Kernel Source Tree?

Kconfig files are distributed across almost every directory in the kernel tree. There is one at the root that ties everything together, and each subsystem has its own. The Kbuild system reads all of them to build the full menu hierarchy you see in menuconfig.

The Kconfig tools live under scripts/kconfig/. The key programs there are mconf (powers menuconfig), nconf (powers nconfig), and conf (handles all non-GUI config targets like defconfig and oldconfig).

🔬 Anatomy of a Kconfig Entry

Every configuration option follows a predictable pattern. Understanding the skeleton first makes all the individual keywords easier to absorb.

config MY_FEATURE
    tristate "My Feature Description"
    depends on SOME_OTHER_OPTION
    default m
    help
      This text is shown when the user presses the Help button
      in menuconfig. Explain what the feature does and when to
      enable it. If unsure, say M.

The symbol name after config becomes CONFIG_MY_FEATURE everywhere — in .config, in include/generated/autoconf.h, and in your Makefiles. Your C source code uses #ifdef CONFIG_MY_FEATURE or IS_ENABLED(CONFIG_MY_FEATURE) to conditionally compile code.

📦 Config Option Types: bool, tristate, int, string

The type keyword is the most important line after config. It defines what values the option can hold and how it appears in menuconfig.

1. bool — On or Off Only

A bool option has exactly two states. When enabled, it generates CONFIG_X=y in .config. When disabled, it appears as # CONFIG_X is not set. There is no module state.

config DEBUG_STACKOVERFLOW
    bool "Check for stack overflows"
    depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
    help
      Enable runtime warnings when the kernel stack space
      on any CPU drops below a safe threshold. Useful for
      catching stack overflow bugs during development.

2. tristate — Built-in, Module, or Off

A tristate option is the most common type for drivers. Y means compiled into the kernel image. M means compiled as a separate .ko file loadable at runtime. N means not compiled at all.

config USB_STORAGE
    tristate "USB Mass Storage support"
    depends on USB && SCSI
    help
      Say Y to build USB mass storage support into the kernel.
      Say M to build it as a module (usb-storage.ko) that can
      be loaded on demand. Say N to exclude it entirely.

3. int — A Numeric Value with Optional Range

An int option stores a whole number. You typically combine it with range to prevent users from entering invalid values.

config LOG_BUF_SHIFT
    int "Kernel log buffer size (16 => 64KB, 17 => 128KB)"
    range 12 25
    default 17
    help
      Sets the size of the printk ring buffer as a power of two.
      Value 17 means 2^17 = 128 KB. Larger values help when
      debugging boot issues where messages scroll by fast.

4. string — A Text Value

config DEFAULT_HOSTNAME
    string "Default hostname"
    default "(none)"
    help
      The system hostname set at boot time before any
      init scripts run. Override it in /etc/hostname later.

🔑 All Important Kconfig Keywords — Quick Reference

🔗 Understanding depends on — Forward Dependencies

depends on is the gatekeeper keyword. It hides an option from menuconfig until all listed conditions are satisfied. Think of it as a prerequisite list. The user must first enable the required option, then this one becomes visible.

# Both must be Y for this option to appear
depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW

# Either one being Y is sufficient
depends on X86 || ARM64

# Negation — hide this option when COMPILE_TEST is enabled
depends on DEBUG_KERNEL && !COMPILE_TEST

# Grouping — FOO1 AND FOO2 AND (FOO3 OR FOO4)
depends on FOO1 && FOO2 && (FOO3 || FOO4)

When a dependency is not met, the option is completely absent from the menu — not greyed out, not present at all. It simply does not appear.

⚡ Understanding select — Reverse Dependencies

While depends on works forward (I need X before I can exist), select works backward (when I am enabled, automatically enable X without asking the user). It is used for low-level helper libraries that your driver needs internally but that the user should not have to know about.

config MY_USB_DRIVER
    tristate "My custom USB device driver"
    depends on USB
    select CRC32
    help
      Driver for the MyDevice USB gadget.
      CRC32 is selected automatically — the user does not
      need to enable it separately.

Important rule: Never select an option that itself has complex depends on requirements. That can create unsatisfied dependency chains and trigger the dreaded “recursive dependency detected” Kconfig error. Use depends on for complex prerequisites, reserve select for simple low-level helpers.

📐 Conditional Default Values — Architecture-Aware Defaults

The default keyword sets what value an option gets when the user has not explicitly changed it. What makes this powerful is that you can write multiple default lines, each with a different condition. The Kconfig parser evaluates them from top to bottom and uses the first one whose condition is true.

config FRAME_WARN
    int "Warn for stack frames larger than (bytes)"
    range 0 8192
    default 2048 if KASAN
    default 1280 if (!64BIT && PARISC)
    default 1024 if (!64BIT && !PARISC)
    default 2048 if 64BIT
    help
      Ask GCC to emit a warning at compile time when any
      function uses a stack frame larger than this size.
      Setting it to 0 disables the warning entirely.

This pattern is common throughout arch/ Kconfig files where each architecture has different reasonable defaults. It is far cleaner than C preprocessor tricks.

👻 Hidden Symbols and the HAVE_* Pattern

A Kconfig entry with no prompt string — just a type keyword with no quoted text after it — is a hidden symbol. Users cannot see or change it in menuconfig. It exists purely as an internal flag for the Kconfig dependency system to use.

# Hidden symbol — no prompt, no user interaction
# Architectures that support this feature select it
config HAVE_DEBUG_STACKOVERFLOW
    bool

# User-visible option that only appears when the architecture
# actually supports it
config DEBUG_STACKOVERFLOW
    bool "Check for stack overflows"
    depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW

The HAVE_* convention means user-visible options only appear on hardware that can actually support them. You will see HAVE_PERF_EVENTS, HAVE_IOREMAP_PROT, HAVE_ARCH_TRACEHOOK, and dozens more throughout the kernel. Always remember: HAVE_* symbols are set by architectures, not by users.

✍ Writing Your First Custom Kconfig Entry — Step by Step

Suppose you are writing a character device driver for an embedded board and want users to be able to choose whether it is compiled in, built as a module, or excluded. Here is the exact workflow.

Step 1 — Create the Kconfig file in your driver directory

# File: drivers/myboard/Kconfig

config MYBOARD_CHARDEV
    tristate "MyBoard Character Device Driver"
    depends on HAS_IOMEM
    default m
    help
      Enable support for the MyBoard character device interface.

      Say Y to compile it directly into the kernel image.
      Say M to build it as a loadable module (myboard.ko).
      Say N to exclude it entirely.

      If unsure, say M.

Step 2 — Include your Kconfig from the parent Kconfig

# File: drivers/Kconfig  — add one line:
source "drivers/myboard/Kconfig"

Step 3 — Hook it into your Makefile

# File: drivers/myboard/Makefile
obj-$(CONFIG_MYBOARD_CHARDEV) += myboard.o

📖 Three Real Kernel Examples Explained (Linux 6.x)

These examples come from lib/Kconfig.debug — the file that generates the “Kernel Hacking” menu. Reading real kernel Kconfig entries is the fastest way to get comfortable with the syntax.

Example 1 — Simple bool with two dependencies

config DEBUG_INFO
    bool "Compile the kernel with debug info"
    depends on DEBUG_KERNEL && !COMPILE_TEST
    help
      Say Y to include DWARF debugging symbols in the kernel image.
      The image will be significantly larger. Essential when using
      gdb, crash, or SystemTap for kernel debugging.

The !COMPILE_TEST dependency prevents debug info from being enabled during automated compile-testing runs, which would slow CI builds dramatically without providing any benefit.

Example 2 — int with range and conditional defaults

config FRAME_WARN
    int "Warn for stack frames larger than (bytes)"
    range 0 8192
    default 2048 if KASAN
    default 1024
    help
      GCC will emit a build-time warning for any function whose
      stack frame exceeds this number of bytes. Set to 0 to
      disable the warning. Requires GCC 4.4 or newer.

In Linux 6.x, the KASAN_EXTRA and GCC_PLUGIN_LATENT_ENTROPY conditions from the old book have been consolidated. The default for KASAN is now simply 2048, and all other cases fall back to 1024.

Example 3 — Hidden capability symbol + user-visible option

config HAVE_DEBUG_STACKOVERFLOW
    bool
    # No prompt — set by architectures that support it

config DEBUG_STACKOVERFLOW
    bool "Check for stack overflows"
    depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
    help
      Say Y to get runtime kernel warnings whenever free stack
      space on any CPU drops below the architecture-defined
      minimum threshold.

HAVE_DEBUG_STACKOVERFLOW has no quoted text after bool, making it invisible in menuconfig. Architecture Kconfig files use select HAVE_DEBUG_STACKOVERFLOW to advertise capability. The user-visible DEBUG_STACKOVERFLOW then only appears on supported architectures.

📄 What the .config File Looks Like After menuconfig

After saving your choices in make menuconfig, everything lands in a plain text file called .config at the root of the kernel source. You can open it with any text editor. Here is what a fragment looks like:

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
CONFIG_FRAME_WARN=2048
# CONFIG_MYBOARD_CHARDEV is not set
CONFIG_LOG_BUF_SHIFT=17

From .config, the build system generates include/generated/autoconf.h. Your C source files include it indirectly through <linux/kconfig.h>. You then use the symbols two ways:

/* Classic way — preprocessor skips the block entirely when off */
#ifdef CONFIG_DEBUG_STACKOVERFLOW
    check_stack_usage();
#endif

/* Modern Linux 6.x way — compiler still sees and type-checks
   the block even when the option is off.
   Dead code is eliminated by constant folding. No runtime cost. */
if (IS_ENABLED(CONFIG_DEBUG_STACKOVERFLOW)) {
    check_stack_usage();
}

📏 Kconfig Indentation Rules — Get This Right or Patches Get Rejected

The Linux kernel has strict rules about whitespace in Kconfig files. Violating them either causes parse errors or gets your patch rejected by maintainers during code review.

# CORRECT — tabs for keywords, tab+spaces for help text
config MY_DRIVER
	tristate "My Driver"
	depends on USB
	help
	  Say Y or M to enable the My Driver.
	  If unsure, say M.

# WRONG — spaces instead of tab before keywords
config MY_DRIVER
    tristate "My Driver"    <-- spaces here will fail or be rejected

Enable “show whitespace” in your editor (VSCode, vim, emacs all support this) to verify tabs versus spaces before submitting any Kconfig patch.

📷 Second Suggested Image for This Post

Create a simple side-by-side comparison image showing the same option in three states as it appears in make menuconfig: [ ] for bool off, [*] for bool on, and <M> for tristate module. Label each with the corresponding .config line it produces. Alt text: “Linux kernel menuconfig bool vs tristate option states — free linux kernel programming tutorial EmbeddedPathashala”.

❓ Frequently Asked Questions — Kconfig and Kernel Configuration

🎯 Interview Questions — Kconfig and Linux Kernel Configuration

These are commonly asked in embedded Linux, BSP, and kernel driver engineering interviews. Read the question first, think through your answer, then expand to read the explanation.