📷 Suggested Image for This Section

Insert a screenshot of make menuconfig with the General Setup submenu open and a custom option highlighted. Alt text: “make menuconfig showing a custom CONFIG_ option in General Setup menu — Linux kernel tutorial”. File name: menuconfig-custom-kconfig-linux-kernel.png.

① Back Up the File Before Editing

Kconfig files are indentation-sensitive. A single wrong tab can break the entire configuration menu. Always back up first:

cp init/Kconfig init/Kconfig.bak

If anything goes wrong, you can restore with cp init/Kconfig.bak init/Kconfig.

② Open the Kconfig File and Find a Good Insertion Point

Open init/Kconfig in any text editor. Scroll through the file to find the area after LOCALVERSION_AUTO and before BUILD_SALT. This is a clean, logical place for a new general setup entry.

vim init/Kconfig

Use /LOCALVERSION_AUTO inside vim to jump directly to that line. Then move a few lines down and prepare to insert.

③ Write Your Kconfig Entry

Insert this block at the chosen location. Use a real Tab character for indentation — not spaces. We will break down each keyword in Section 5.

config EP_MYFEATURE
	bool "Enable My Custom Feature (EmbeddedPathashala demo)"
	default n
	help
	  This is a demonstration Kconfig option for the
	  EmbeddedPathashala Linux kernel programming course.

	  When enabled, the kernel includes ep_myfeature.c
	  at build time.

	  If unsure, say N.

cat -A init/Kconfig | grep -A5 "EP_MYFEATURE"

④ Launch menuconfig and Enable Your Option

Save and exit the editor, then run the configuration interface:

make menuconfig

Navigate to General Setup. Scroll down until you see Enable My Custom Feature. Press Space to toggle it on — you will see [*] appear. Press Esc Esc to exit the submenu and choose Yes when asked to save.

⑤ Check the .config File

After saving from menuconfig, verify the option was recorded:

grep "EP_MYFEATURE" .config

When enabled you should see:

CONFIG_EP_MYFEATURE=y

When disabled you will see:

# CONFIG_EP_MYFEATURE is not set

The .config file is the source of truth for your build. The actual C header has not been generated yet — that happens in the next step.

⑥ Build the Kernel and Check autoconf.h

Run the kernel build. Use -j$(nproc) to utilise all CPU cores — this is the modern recommended approach for Linux 6.x builds, much faster than the old -j4 hardcoded in older examples:

make -j$(nproc)

Once the build completes, check the auto-generated header:

grep "EP_MYFEATURE" include/generated/autoconf.h

Expected output:

#define CONFIG_EP_MYFEATURE 1

This #define is what your kernel C code will see. The kbuild system generates this file automatically from .config during every build.

💡 Why Write Good Help Text?

The help section is read by engineers who are trying to decide whether to enable your feature on their system. Explain what the feature does, what it depends on, what the performance or security implications are, and what the safe default is. Poor help text leads to configuration mistakes that are hard to debug.

📷 Suggested Image for Section 9

A side-by-side terminal screenshot showing make -j4 on an older system vs make -j$(nproc) on a 16-core machine to illustrate the performance difference. Alt text: “Linux kernel build with make -j$(nproc) for parallel compilation — Linux 6.x tutorial”. File name: linux-kernel-make-jnproc-parallel-build.png.

What is the difference between a Kconfig file and a .config file?

A Kconfig file is a declaration file written by the kernel developer. It defines what options exist, their types, default values, dependencies, and help text. There are hundreds of Kconfig files across the kernel source tree, one per subsystem. The .config file is the user’s configuration record — it stores the choices the user made when running make menuconfig. The .config file is in the kernel root directory and is read by the build system. Kconfig files are read-only from the user’s perspective; .config is what changes when you configure the kernel.

Why is my new Kconfig option not showing up in menuconfig?

The most common reasons are: (1) You have a depends on X clause and X is not enabled — navigate to X and enable it first. (2) Your entry is inside a menu ... endmenu block that is collapsed — expand it. (3) There is a syntax error in your Kconfig entry (wrong indentation, missing tab) — run make menuconfig from the terminal and look for error messages printed before the UI launches. (4) You edited the wrong Kconfig file — double-check which menu your file belongs to and which Kconfig file controls that menu.

Can I add a Kconfig option without rebuilding the entire kernel?

Yes, partially. You can add the entry to the Kconfig file, run make menuconfig to update .config, and then run make -j$(nproc). The build system is incremental — it only recompiles files that changed. If your new option only adds one new source file, only that file and any modules that depend on it will be rebuilt. The full kernel image will be re-linked, but the compilation step is minimal.

What is the difference between select and depends on in Kconfig?

depends on X is a forward dependency: your option only appears in the menu when X is already enabled. select X is a reverse dependency: when the user enables your option, X is automatically enabled too. The kernel style guide recommends using select only for invisible low-level helper libraries (like crypto implementations) that users would not want to manage manually. For anything users might want independent control over, use depends on instead.

Is it safe to use select in Kconfig?

Use select with caution. When you select X, you force X to be enabled regardless of whether X’s own depends on clauses are satisfied. This can create dependency loops and inconsistent configurations. The rule of thumb: only use select for options that have no dependencies themselves (leaf nodes in the dependency graph). For anything complex, prefer depends on and let the user resolve dependencies explicitly.