Lesson 6	When Should You Build a Custom Linux Kernel?
Objective	Evaluate the purpose, alternatives, and maintenance cost of a custom kernel before starting a build.

When Should You Build a Custom Linux Kernel?

A custom kernel is useful when it answers a specific technical question. You might need to test a patch, investigate a regression, develop a driver, or enable a configuration option that the available distribution kernel does not provide. Compiling simply to obtain a newer version is usually unnecessary when a supported package already supplies the required capability.

Investigate alternatives first

Check the running kernel, available packages, module metadata, and documented runtime settings. Routing, firewall behavior, resource limits, and other system functions often have configuration interfaces that do not require a new kernel. A driver that is already available as a module can usually be loaded without compilation.

On RHEL, a supported update can contain fixes backported to the distribution's kernel series. An older-looking upstream version number alone does not prove that a RHEL kernel lacks a security fix or feature. Check the vendor's errata and package documentation.

State a measurable reason

Proposed change	First question
Support new hardware	Does an available signed kernel or driver package already support it?
Change a kernel option	Is it a build-time setting, a module parameter, or a runtime setting?
Improve performance	Which repeatable workload and measurement will show an improvement?
Test a fix	Which source revision or patch changes the behavior, and how will it be reproduced?

For example, a useful lab objective is “verify that this patch corrects the device failure reproduced by these steps.” “Make the kernel faster” is too broad to assess.

Understand what you take responsibility for

An upstream source build is not automatically covered by the distribution's support or update process. You must track its source version, configuration, patches, toolchain, signing requirements, and future fixes. Out-of-tree modules may need to be rebuilt or replaced. A kernel that works in one virtual machine is not automatically suitable for other hardware.

Keep a known-good kernel and its boot entry. Test in a VM or dedicated lab with console access, and check storage, networking, filesystems, application behavior, and logs after booting. Include failure and rollback steps in the test plan.

Separate the benefits from the costs

Removing unused features can reduce a build or runtime footprint, but configuration changes can also remove drivers needed only occasionally. A smaller configuration does not by itself establish better performance or security. Evaluate the actual result, including the work required to keep it maintained.

Proceed when you can name the required change, explain why existing facilities are insufficient, and test the outcome. The next lesson prepares the source tree, build tools, and lab environment.

References