📚 Linux Kernel Programming Series – Chapter 2

Prerequisites

Before this lecture you should be comfortable with basic Linux terminal commands (ls, cp, cd, make) and have a general understanding of what a kernel is. Completing Lecture 11 on downloading and extracting the kernel source is recommended.

💡 Real-World Analogy

Think of it like ordering a custom laptop. You choose the CPU, RAM, storage, GPU, and display – the factory builds only what you ordered. The kernel configuration system works exactly the same way. You specify what to include; everything else is left out of the final binary.

🏭 What is a BSP Team?

BSP stands for Board Support Package. In companies that build embedded Linux products — routers, cameras, set-top boxes, automotive systems — a dedicated BSP team is responsible for porting the Linux kernel to the specific hardware. One of their primary tasks is carefully crafting the kernel .config for that product: enabling only the drivers the hardware actually has, disabling debug features in production, enabling security hardening options, and tuning performance-related config symbols. A well-crafted BSP kernel config directly impacts boot time, memory footprint, power consumption, and attack surface of the final product.

Approach 1 – Use the Architecture defconfig (Best for Embedded)

Pick the defconfig file that matches your SoC, copy it to .config, and you have a verified starting point the kernel maintainers have already tested for that platform. This is the standard method used by every BSP team and embedded Linux engineer.

# Configure for Samsung Exynos (32-bit ARM) cross-compilation
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-

# Approach A: manual copy
cp arch/arm/configs/exynos_defconfig .config
make menuconfig

# Approach B: let kbuild copy it (kernel 6.x recommended)
make ARCH=arm exynos_defconfig

After running the defconfig target you can immediately open menuconfig to add any product-specific options your board needs.

Approach 2 – Copy Your Distro’s Existing Config (Best for Desktop)

If you are building a kernel for an x86-64 desktop or server, the fastest shortcut is to start with the config your current Linux distribution already uses. This config has been tested by thousands of users and handles almost all common hardware out of the box.

# The running kernel's config is stored in /boot
# Copy it as the starting .config for your new build
cp /boot/config-$(uname -r) /path/to/kernel/source/.config

# Then update it for any new symbols in the newer kernel version
cd /path/to/kernel/source
make olddefconfig

The olddefconfig step is important: if you are building a newer kernel version than you are currently running, there will be new config symbols that do not exist in the old .config. olddefconfig sets them all to their kernel-defined defaults without asking you anything — perfect for automated workflows.

Keep in mind: distro configs tend to be very large because they support every possible piece of hardware. Build times will be long. If you want a leaner, faster build, use Approach 3.

Approach 3 – localmodconfig (Recommended for Desktop / Learning)

This is the smartest approach for x86-64 development. The idea is simple: why compile drivers for hardware you do not even have? The localmodconfig target looks at which kernel modules are currently loaded on your running system, and builds a .config that only includes those — plus core kernel features. Everything else is disabled, giving you a much smaller config and significantly faster build times.

# Step 1: Snapshot the currently loaded kernel modules
lsmod > /tmp/lsmod_snapshot.txt

# Step 2: Generate lean .config from that snapshot
cd /path/to/kernel/source
make LSMOD=/tmp/lsmod_snapshot.txt localmodconfig

When you build a newer kernel version than you are currently running (common — building kernel 6.x but running 5.x), kbuild will encounter new config options that did not exist before. For each one it will ask you what value to set. Pressing Enter accepts the default. To automate this:

# Accept all defaults for new options automatically
yes "" | make LSMOD=/tmp/lsmod_snapshot.txt localmodconfig

Pro Tip: Before running any config target on a fresh kernel source tree, always run make mrproper first. This removes any stale generated files from previous builds and ensures a completely clean starting state. Skipping this step can cause confusing build errors.

# Clean slate first — always
make mrproper

# Then configure
make LSMOD=/tmp/lsmod_snapshot.txt localmodconfig

Common Mistake – Editing .config Manually Without Running menuconfig After

If you manually edit .config in a text editor and then run make without running make olddefconfig first, the build may pick up inconsistent dependency states. Always run make olddefconfig after any manual edit to let kbuild resolve and validate dependencies before building.

Q1. What is the .config file in the Linux kernel and why is it important?

The .config file is a plain-text file at the root of the kernel source tree that stores all configuration choices for a particular build. Every feature, driver, and subsystem is represented by a config symbol set to y (built-in), m (module), or left unset (disabled). The kbuild system reads this file to decide what code to compile. Without a valid .config, the kernel cannot be built.

Q2. Why can you not use an x86-64 kernel .config for an ARM embedded board?

A kernel config is tightly tied to the CPU architecture. x86-64 and ARM have completely different hardware — different instruction sets, memory management units, interrupt controllers, and boot mechanisms. An x86-64 config enables drivers and options that do not exist or make no sense on ARM hardware. Even if the build does not fail, the resulting binary will not work on the ARM board. You must always start from an architecture-appropriate defconfig.

Q3. What is localmodconfig and when would you use it?

localmodconfig is a kbuild target that builds a .config based on the kernel modules currently loaded on the running system. You first save the output of lsmod to a file and pass it via the LSMOD variable. The result enables only the modules your hardware actually uses, disabling everything else. It is the recommended approach for developers who want to quickly build and test a custom kernel on their own x86-64 machine. It is not suitable for embedded targets where the hardware is different from the build host.

Q4. What does make mrproper do and why should you run it first?

make mrproper removes all generated files including the .config, auto-generated headers, and leftover object files from any previous build. If you skip it on a fresh kernel source, stale headers can cause subtle and confusing build errors. Running mrproper guarantees you are starting from a completely clean state. The name comes from the German word for “proper” — it means a spotless clean.

Q5. What is the role of the BSP team in kernel configuration for embedded products?

BSP stands for Board Support Package. The BSP team in an embedded product company adapts the Linux kernel to specific hardware. A major part of their work is crafting the kernel .config for that product: enabling only the drivers the hardware has, disabling debug features for production builds, enabling security hardening options, and tuning performance-related symbols. A well-crafted BSP config directly impacts boot time, memory usage, power consumption, and attack surface of the product.

Q6. What is syncconfig and when does it run?

syncconfig is an internal kbuild step that converts .config into C header files under include/generated/ and include/config/. The kernel’s C source files use #ifdef CONFIG_XXX guards that read from these generated headers to include or exclude code. You never call syncconfig manually — kbuild runs it automatically when you invoke make after a .config is created or changed. It was previously called silentoldconfig before being renamed.

Q7. What is the difference between make clean and make mrproper?

make clean removes most generated object and binary files but preserves the .config and enough support to rebuild. Use it when you have changed source files and want to recompile without reconfiguring. make mrproper removes everything including .config, generated headers, and all backup files — it gives you an absolutely clean source tree. Use it when starting a completely fresh configuration from scratch.

📚 Linux Kernel Programming Series – Chapter 2