PREV_LEC | NEXT_LEC

What You Will Learn

• How to launch menuconfig, xconfig, and gconfig and when to prefer each one
• Why you must always pass ARCH= when configuring the kernel for an embedded target
• What a defconfig file is and why you almost never start configuration from scratch
• How oldconfig lets you carry a configuration forward to a newer kernel version safely
• How to search for a configuration option without memorizing its exact menu path

Prerequisites

• Completion of, or familiarity with, the previous lecture on Kconfig data types and dependencies
• A kernel source tree and a working cross-compiler or native toolchain
• ncurses development headers installed if you plan to use menuconfig

The Three Configuration Front-Ends

Kconfig itself is just a parser and a data model — it does not draw anything on screen. That job belongs to separate front-end tools, and the kernel ships three of them, all reading the exact same Kconfig files and producing the exact same kind of .config output. They differ only in interface.

All three are launched the same way, through make, and — critically for embedded work — you must tell the build system which architecture you are targeting. Without it, the build system assumes the architecture of the machine you’re running on, which is almost never what you want when cross-compiling for an ARM or RISC-V board.

$ make ARCH=arm menuconfig

Inside menuconfig, a highlighted [*] means the option is compiled directly into the kernel image, while an <M> means it will be built as a separate loadable module. Pressing Y, N, or M on a highlighted line sets the state directly.

Searching Instead Of Scrolling

Kernel menus are deep — some subsystems bury an option six or seven submenus down. Every one of these tools has a search function so you don’t have to memorize the path. In menuconfig, press / to open the search box. In xconfig, the search lives in the edit menu. Either way, search using the bare option name, without the CONFIG_ prefix — searching for CONFIG_EP_DEMO_DRIVER will return nothing, but searching for EP_DEMO_DRIVER will find it immediately and tell you exactly which submenu it lives in.

Starting From A defconfig Instead Of Scratch

With thousands of configuration options across a modern kernel tree, manually toggling everything for every new board is unrealistic. The kernel solves this with pre-built configuration files, stored under arch/$ARCH/configs/, each one representing a known-good baseline for a specific SoC or a family of SoCs. You load one with a target name matching the file (minus the _defconfig suffix convention), for example:

$ make ARCH=arm multi_v7_defconfig

This particular target configures the kernel to run across a wide range of ARMv7-A boards. It is a generic, widely-applicable starting point rather than a configuration tuned for one specific product. When you are working with a vendor board support package instead, the vendor typically ships its own defconfig file as part of that package, and figuring out which one to load is usually the very first step in any board bring-up.

Carrying A Configuration Forward With oldconfig

Board configurations are living documents — they get updated, tuned, and carried across kernel version upgrades over the life of a product. Re-toggling every option from scratch each time you move to a newer kernel source tree would be both slow and error-prone. The oldconfig target exists for exactly this situation.

The workflow is straightforward: copy your existing .config from the old kernel source directory into the new one, then run:

$ cp /path/to/old-kernel/.config .
$ make ARCH=arm oldconfig

oldconfig walks through every option that exists in the new kernel version but has no value in the copied .config — typically new features added since the old kernel was released — and interactively asks you to decide on each one. Everything that already has a value from the old configuration is carried forward untouched.

oldconfig has a second, less obvious use: validating a .config file that you or a script edited by hand. Every generated .config begins with an “Automatically generated file; DO NOT EDIT” warning, but in practice hand-editing does happen, and running oldconfig afterward will catch inconsistencies. It’s generally safe to proceed past that warning when you know what you changed.

Practical Walkthrough

Here is a realistic sequence for bringing up a generic ARMv7 target from a clean checkout:

# Start from a known-good baseline for a wide range of ARMv7 SoCs
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- multi_v7_defconfig

# Fine-tune interactively, e.g. enable the EP_DEMO_DRIVER from the last lecture
$ make ARCH=arm menuconfig
# (press / then type EP_DEMO_DRIVER, hit Enter, select it with Y or M)

# Build using the resulting .config
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc)

Real-World Use Cases

• New board bring-up — load the closest matching defconfig, then tune with menuconfig for board-specific peripherals
• Kernel version upgrades on shipping products — copy the field configuration forward with oldconfig instead of re-deriving it
• CI pipelines — menuconfig‘s text interface works cleanly over SSH and inside containers where no display is available

Common Mistakes And Troubleshooting

• Forgetting ARCH= — the build silently defaults to your host architecture, producing a configuration that won’t even boot on the target
• Running oldconfig non-interactively in scripts and missing new prompts — for unattended builds, pair it with sensible defaults or a scripted answer file rather than letting prompts hang
• Editing .config by hand and never re-validating it — always follow a manual edit with oldconfig to catch dependency violations
• Assuming every board has a dedicated defconfig — many boards share a generic multi-platform defconfig and are told apart by the device tree instead

Best Practices

• Always start from the closest matching defconfig rather than a blank configuration
• Commit your board’s .config (or the defconfig derived from it) to source control alongside the rest of the board support package
• Use oldconfig — not a fresh defconfig — when moving a shipping product to a newer kernel, so field-tuned settings aren’t lost
• Prefer menuconfig in any environment without a reliable graphical display, including most CI runners

Performance And Security Considerations

The configuration front-end you choose has no runtime performance impact — it only affects the human experience of configuring the kernel, not the resulting binary. Security-wise, the discipline matters more than the tool: an oldconfig run that silently accepts a new security-relevant option’s default value (rather than deliberately reviewing it) is a common way that hardening regressions slip into a product across kernel upgrades. Treat every prompt oldconfig raises as worth reading, not just clicking through.

Summary And Key Takeaways

• menuconfig, xconfig, and gconfig are interchangeable front-ends over the same Kconfig data
• Always specify ARCH= when configuring for an embedded target
• defconfig files under arch/$ARCH/configs/ give you a known-good starting point instead of a blank sheet
• oldconfig carries a configuration forward across kernel versions and only prompts for genuinely new options

Conclusion

The configuration tools covered here are the day-to-day workhorses of embedded kernel work — you will run menuconfig and oldconfig far more often than you will write a brand-new Kconfig entry. Getting comfortable with defconfig baselines and the oldconfig upgrade path is what separates a smooth kernel version bump from a multi-day configuration archaeology project. This lecture continues our free embedded linux course; next up, we look at how to give your custom build a distinct, traceable identity with CONFIG_LOCALVERSION.

Frequently Asked Questions

PREV_LEC | NEXT_LEC