📸 Suggested Image for This Section

A screenshot of make menuconfig running in terminal showing the General Setup submenu with a custom option highlighted. Alt text: “Adding a custom Kconfig option to Linux kernel menuconfig General Setup menu”

📌 Scale in kernel 6.x: The Linux 6.x source tree contains over 1,700 Kconfig files. Each subsystem owns its own. This modularity is what keeps the configuration system manageable despite the enormous scale of the kernel.

💡 Pro Tip — Find Any Option’s Kconfig File in Seconds: Inside make menuconfig, navigate to any option and press the ? key. The help screen shows the exact Kconfig file and line that defines that option. This is the fastest lookup method — no grep needed.

config MY_DRIVER
    bool "Enable my custom driver"
    default n
    help
      Set this to Y to include my custom driver in the kernel.
      If unsure, say N.

config MY_DEBUG_FLAG
    bool "Enable debug mode"
    default n

config MY_USB_DRIVER
    tristate "My USB driver"
    depends on USB

Step 1 — Find and Back Up the Right Kconfig File

We want our option in General Setup. From the table above, that means init/Kconfig. Always back up before editing:

# From the root of your kernel source tree
$ cp init/Kconfig init/Kconfig.bak

Step 2 — Add Your Entry Inside init/Kconfig

Open init/Kconfig in your editor. Find a logical place — near the LOCALVERSION_AUTO area is a good spot used by the community. Add this block:

config EP_MY_DRIVER
    bool "EmbeddedPathashala: Enable my custom driver support"
    default n
    help
      Enable this option to include the EmbeddedPathashala custom
      driver in your kernel build.

      If unsure, say N.

Step 3 — Run menuconfig to Verify It Appears

$ make menuconfig

Navigate to General Setup. Your new entry should appear in the list as “EmbeddedPathashala: Enable my custom driver support”. Press ? on it to confirm the help text displays correctly. Press Y to enable it and save the config.

Step 4 — Wire Up Your Makefile

The Kconfig entry alone does not compile anything. You must tell the build system what to build when the option is selected. Edit the Makefile in your driver’s directory:

# In your driver's Makefile — for example: drivers/mydriver/Makefile

# When CONFIG_EP_MY_DRIVER=y  → obj-y  → built into kernel image
# When CONFIG_EP_MY_DRIVER=m  → obj-m  → compiled as a .ko module
# When CONFIG_EP_MY_DRIVER=n  → nothing → file not compiled at all

obj-$(CONFIG_EP_MY_DRIVER) += my_driver.o

The $(CONFIG_EP_MY_DRIVER) variable is automatically substituted with y, m, or left empty by the build system, based on what the user selected.

Step 5 — Use the Config Symbol in Your C Code

The kernel build system auto-generates a header file include/generated/autoconf.h from your .config. When CONFIG_EP_MY_DRIVER=y, the macro CONFIG_EP_MY_DRIVER is defined as 1 in that header, which is automatically included everywhere in the kernel. You can use it like this:

/* my_driver.c */
#include <linux/kernel.h>

#ifdef CONFIG_EP_MY_DRIVER
static void my_feature_init(void)
{
    pr_info("EP driver: custom feature is active\n");
}
#endif

config MY_USB_DRIVER
    tristate "My USB driver"
    depends on USB

config MY_CRYPTO_DRV
    tristate "My crypto driver"
    select CRYPTO_AES

⚠️ Use select with Great Caution: select overrides the user’s explicit choice for the selected symbol. This can create circular dependencies (A selects B, B selects A) that cause the Kconfig system to fail. It can also force-enable a symbol that has its own unmet dependencies, leading to confusing build errors. The kernel community’s guidance is clear: prefer depends on in almost all cases and reserve select only for well-understood, non-cyclic hard requirements.

# Approach 1 — Plain sub-menu (always visible as a group)
menu "EmbeddedPathashala Driver Options"

config EP_FEATURE_A
    bool "Feature A"
    default n

config EP_FEATURE_B
    bool "Feature B"
    default n

endmenu


# Approach 2 — menuconfig (submenu only appears when top-level is enabled)
menuconfig EP_MY_SUBSYSTEM
    bool "EmbeddedPathashala Subsystem"
    default n

if EP_MY_SUBSYSTEM

config EP_FEATURE_A
    bool "Feature A (requires EP subsystem)"
    default n

config EP_FEATURE_B
    bool "Feature B (requires EP subsystem)"
    default n

endif

📸 Suggested Image for This Section

A side-by-side terminal screenshot showing the same menuconfig before and after adding the custom Kconfig entry — the new item visible in the General Setup submenu. Alt text: “Custom CONFIG_EP_MY_DRIVER option visible in Linux kernel menuconfig General Setup”

Do I need to modify any other file besides Kconfig and the Makefile to add a new kernel option?

For a driver in an existing directory, editing the Kconfig file and the Makefile in that directory is sufficient. If you are creating a brand new subdirectory under drivers/, you also need to add a source "drivers/mydir/Kconfig" line in the parent drivers/Kconfig and an obj-y += mydir/ or equivalent line in the parent drivers/Makefile so the build system knows to descend into your directory.

What happens to CONFIG_MY_OPTION in autoconf.h when it is set to m (module)?

When an option is set to m, the generated autoconf.h defines CONFIG_MY_OPTION_MODULE as 1 rather than CONFIG_MY_OPTION. This distinction matters for code that needs to behave differently when built as a module versus built in. In most cases you do not need to care about this because your Makefile handles the compilation difference automatically via obj-$(CONFIG_MY_OPTION).

Can a single Kconfig file define options for multiple menus?

Typically, one Kconfig file drives one menu or submenu. However, there is nothing technically preventing a Kconfig file from defining options that appear in multiple places — the Kconfig language supports this through menu structure keywords. In practice, keeping one Kconfig file per subsystem directory is a strong convention in the kernel because it makes the build system easy to understand and maintain.

How do I search for a specific CONFIG_ symbol inside make menuconfig?

Press the / key inside menuconfig to open a search box. Type the symbol name (without the CONFIG_ prefix) and the UI will show you every matching option, where it is located in the menu tree, and which Kconfig file defines it. This is the fastest way to navigate the menu when you know the symbol name you are looking for.

Q1. You write a new Linux driver. What files must you create or modify to expose a new Kconfig option for it in make menuconfig?

At minimum, two things must be done. First, add a config entry in the appropriate Kconfig file for the subsystem your driver belongs to — for a character device, this would typically be near drivers/char/Kconfig. Second, update the Makefile in your driver’s directory with obj-$(CONFIG_MY_DRIVER) += my_driver.o. If your driver is in a new subdirectory, you also need to add source and obj-y += lines in the parent directory’s Kconfig and Makefile respectively so the build system descends into your directory.

Q2. What is the difference between bool and tristate in a Kconfig entry? When would you choose each one?

A bool option supports two states: y (compiled in) and n (disabled). A tristate option adds a third state: m (built as a loadable kernel module). Use bool for features that are tightly integrated with the kernel core and cannot be meaningfully unloaded at runtime — architecture options, core security features, scheduler settings. Use tristate for device drivers, file systems, and protocol implementations that can be loaded and unloaded at runtime. If in doubt for a driver, use tristate.

Q3. What is the difference between depends on and select in Kconfig? Why should select be used with caution?

depends on makes your option invisible in the menu unless the listed dependency is already enabled by the user. select silently forces the listed symbol to y when the user enables your option. The risk with select is circular dependencies — if A selects B and B selects A, the Kconfig resolver cannot find a valid configuration and produces an error. It can also force-enable symbols that have their own unmet dependencies, causing cryptic build failures. The kernel community’s strong recommendation is to use depends on in nearly all cases.

Q4. How do kernel Makefiles know whether to build a driver as built-in, a module, or skip it entirely, based on the user’s menuconfig selection?

The Makefile uses the obj-$(CONFIG_SYMBOL) pattern. The Kbuild system substitutes $(CONFIG_SYMBOL) with the value from .config. If the value is y, the line becomes obj-y += my_driver.o and the object is linked into the kernel image. If the value is m, it becomes obj-m += my_driver.o and a .ko module file is produced. If the value is n or the symbol is absent, the variable expands to nothing and the line has no effect — the file is not compiled.

Q5. How would you quickly find which Kconfig file defines a specific option you see in make menuconfig?

The fastest method is to navigate to that option in menuconfig and press the ? key. The help screen shows the exact Kconfig file path and the config symbol name. Alternatively, use the / search key inside menuconfig. From the command line, grep -r "config SYMBOL_NAME" . from the kernel source root will also find it. The ? key approach is generally fastest because it gives the file path directly without needing to parse grep results.

Q6. What is autoconf.h, how is it generated, and why do kernel C files not need to explicitly include it?

include/generated/autoconf.h is a C header file automatically generated by the Kbuild system from the .config file after every configuration change. For each option set to y, it writes #define CONFIG_SYMBOL 1. For m options, it writes #define CONFIG_SYMBOL_MODULE 1. Options set to n are simply not defined. Kernel C files do not need to explicitly include it because the Kbuild compilation flags automatically pass -include include/generated/autoconf.h (via the -include gcc flag) to every compiled translation unit, making all CONFIG_ macros automatically available everywhere.