💡 Three Benefits of Proper Kernel Configuration

• Smaller and faster: No bloat from drivers you do not need. Smaller image, faster boot.
• More secure: Fewer features means a smaller attack surface. Unused subsystems cannot be exploited.
• Purpose-built: A kernel tuned exactly for your hardware and use case performs significantly better.

Kconfig Files — The Menu of Available Options

Every directory in the kernel has its own Kconfig file listing what features can be turned on or off in that directory. These files define what configuration options exist, what their descriptions are, and what their dependencies are. Think of them as the menu from which you order.

Makefiles — What to Compile Based on Your Choices

Each directory also has a Makefile that tells kbuild what source files to compile based on which CONFIG options are enabled. A typical line looks like:

Three States for Every CONFIG Option

y (Yes / Built-in): The feature is compiled directly into the kernel image. It is always available from the moment the kernel boots. Boot-critical features like the scheduler and memory management must be set to y.

m (Module): Compiled as a separate .ko file that can be loaded and unloaded at runtime with modprobe. Useful for drivers you might or might not need depending on the hardware present.

n (Not set / Disabled): Completely excluded. No code is compiled for this feature. Saves both kernel image size and runtime memory.

💡 Tip — Read Your Running Kernel’s Config

On your current Ubuntu install, the config used to build the running kernel is available here. Try it now:

make menuconfig — Most Commonly Used Method

Opens a text-based, menu-driven configuration interface directly in the terminal. Works over SSH, requires no graphical display. This is what most embedded developers and students in any free Linux kernel programming course use because it runs anywhere — on a headless server, inside Docker, or over a remote SSH session.

make xconfig — Graphical Configuration (Requires Desktop)

Opens a GUI-based configuration tool built with Qt. Easier to explore with a mouse, has a built-in search feature, and shows option descriptions clearly. Only works when you have a desktop environment available. Good for learning and exploration when you are on a local machine.

make defconfig — Good Starting Point

Creates a reasonable default .config based on the architecture you are building for. For embedded ARM boards, chipset vendors and board manufacturers often provide their own defconfig file. For example, the Raspberry Pi 4 has bcm2711_defconfig.

make oldconfig — For Kernel Version Upgrades

When you upgrade from one kernel version to a newer one, the new kernel may have added new CONFIG options that your existing .config does not have. make oldconfig reads your existing config and only asks you about the new options — keeping everything else unchanged. Always use this when bumping from kernel 6.8 to 6.9, for example.

make localmodconfig — Fastest Compile for Your Machine

This is a clever time-saver. It looks at what kernel modules are currently loaded on your running system and disables everything else. The result is a dramatically smaller .config — only the drivers your hardware actually uses. Compile time drops from 60 minutes to often under 15 minutes on the same machine.

What Output Files Does the Build Produce?

Verifying Your New Kernel After Reboot

What Is a Device Tree (DTB) and Why Does ARM Need It?

On ARM and RISC-V embedded boards, there is no standard way for the kernel to auto-detect what hardware is connected (unlike x86 which uses PCI and ACPI for hardware discovery). Instead, a Device Tree Blob (DTB) is a small binary file that describes the hardware layout — which peripherals exist, at which memory addresses, which interrupt lines they use, and how they are connected.

The bootloader loads both the kernel Image and the DTB and passes the DTB memory address to the kernel at boot time. The kernel reads it and knows exactly what hardware it has to drive.

Built-in vs Module — Which Should You Choose?

In embedded Linux, you often face this choice. Building everything as y (built-in) makes boot faster and avoids the overhead of loading modules at runtime — important for real-time systems. Using m (modules) produces a smaller kernel image and lets you load drivers on demand — useful when you have many optional peripherals. Most embedded products that ship a fixed hardware configuration prefer built-in for their core drivers.

⚠ Common Mistake 1 — Skipping the Configuration Step

Even if you do not want to change any settings, you must run at least one configuration step (at minimum make oldconfig) before compiling. Certain auto-generated headers that the build system needs are only produced during configuration. Skipping it causes mysterious compile errors.

⚠ Common Mistake 2 — Missing Build Dependencies

The kernel build needs several packages installed. If you see errors about missing openssl/ssl.h or libelf.h, install the dependencies:

⚠ Common Mistake 3 — Forgetting to Run modules_install

After building, if you run make install but forget sudo make modules_install, the new kernel will boot but any feature you compiled as a module will fail to load. Always run modules_install before rebooting into the new kernel.

⚠ Common Mistake 4 — Wrong ARCH or CROSS_COMPILE for Embedded

If you forget to set ARCH and CROSS_COMPILE before configuring or compiling for an ARM board, the build system will default to x86 and produce a kernel your ARM board cannot run. Always set these before any make command when cross-compiling.

Q1. What is the kbuild system and what problem does it solve?

kbuild is the Linux kernel’s build infrastructure, built on top of GNU make. It solves the problem of managing a massively complex codebase where what gets compiled depends entirely on user-chosen configuration options. It ties together Kconfig (option definitions), the .config file (user choices), and per-directory Makefiles (what to compile) into a single coordinated build system.

Q2. What is the difference between CONFIG_FOO=y and CONFIG_FOO=m?

CONFIG_FOO=y means the feature is compiled into the kernel image — always present from the moment the kernel boots, no additional loading required. CONFIG_FOO=m means it is compiled as a separate loadable kernel module (.ko file) that can be loaded later with modprobe. Modules allow flexibility but add a small latency at load time. Boot-critical features must always be y.

Q3. What is the purpose of make localmodconfig?

It generates a minimal .config based only on the kernel modules currently loaded on your running system (from lsmod output). Everything else is disabled. This dramatically reduces compile time because you are not compiling hundreds of drivers your hardware does not use. It is extremely useful during development but should not be used for building kernels intended to run on other machines with different hardware.

Q4. What are Kconfig files and how do they differ from Makefiles?

Kconfig files define what configuration options exist — their descriptions, allowed states (y/m/n), and dependencies on other options. Makefiles define what source files to compile based on those options. A typical Makefile pattern: obj-$(CONFIG_BLUETOOTH) += bluetooth.o — compile bluetooth.o only if CONFIG_BLUETOOTH is set. The two work together: Kconfig defines the menu, Makefile acts on the result.

Q5. What is cross-compilation and why is it needed for embedded Linux development?

Cross-compilation is building software on one machine type (host, typically x86) to run on a different machine type (target, typically ARM or RISC-V). It is needed in embedded development because the target device has a slow CPU and limited storage and RAM. You use your powerful development machine with a cross-compiler toolchain (like aarch64-linux-gnu-gcc) to produce binaries for the target architecture quickly.

Q6. What is a Device Tree and why does ARM Linux need it while x86 does not?

A Device Tree is a data structure (compiled into a .dtb binary file) that describes the hardware layout of a board to the kernel — what peripherals are connected, at which memory addresses, which interrupt lines they use. ARM and RISC-V embedded boards require it because they lack standardized hardware discovery mechanisms like PCI or ACPI that x86 machines use. Without a Device Tree the kernel would not know what hardware it has to initialize and drive.

Q7. When should you use make oldconfig versus make menuconfig?

Use make oldconfig when you are upgrading an existing kernel to a newer version and want to keep your existing configuration as-is, only responding to new options added in the newer kernel. Use make menuconfig when you want to interactively explore and change configuration options — starting fresh, doing a significant reconfiguration, or enabling a specific new driver or feature.

Q8. What command tells you the number of CPU cores available for parallel compilation?

The command nproc prints the number of available processing units. It is used with the -j flag of make: make -j$(nproc). This allows make to compile multiple source files simultaneously, dramatically reducing build time. On a quad-core machine this alone cuts compile time to roughly one quarter of the serial build time.