Linux: Custom Kernels Trim Fat and Tune Performance
Your Linux distribution probably arrived with a "kitchen sink" kernel. It doesn't take much to build a better one that's tuned to your hardware's needs.
I have some shocking news: despite the astonishing growth of Linux, there is a whole new generation of Linux users who have never, ever compiled a kernel. How to account for this sad state of affairs? Perhaps it's because the distribution maintainers are doing such fine jobs it's not necessary. Maybe users just don't know that they can. Whatever the reasons, today we're taking a tour of some of the different ways to customize the Linux kernel. First we'll learn the old reliable generic way, and then take a tour of the Fedora Way and the Debian Way of customizing kernels.
A word of warning: while building a custom kernel isn't all that difficult, it is complex and time-consuming, and when you're all finished you might be the proud parent of a non-booting kernel. The good news is you can have as many do-overs as you want without hurting your system. Any Linux system can have any number of kernels and you can choose which one to boot to, so never delete old kernels until you're certain your new one works correctly. Your system will not try to boot to a new kernel until you explicitly configure it to do so, so it can't sneak up on you. So you can go on a wild spree and build and test a whole army of new kernels if you like.
Give yourself a couple of gigabytes of disk space to play with. You'll need it to hold your kernel sources and build tools and other utilities, plus you'll need 500 megabytes just for the interim files created during the build process, and you'll need a place to keep your nice new kernels and kernel modules.
You should have the lshw and lspci commands installed in case you need to look up hardware information. Run the update-pciids command first to bring them up-to-date. cat /proc/cpuinfo displays your CPU specs.
Why would you even want to do this? For a number of reasons: to get extra functionality, to weed out unneeded features, to try for better performance, to help with testing new patches, or just because you want to know how. The last two reasons are the best ones. I wish everyone had curiosity and a desire to tinker and improve things.
Most general-purpose Linux distributions ship with kernels and sets of modules that try to please everyone and support all the hardware in the world, so you end up with a couple hundred megabytes of kernel + modules fattening your system. This raises security concerns, and some things are just plain silly such as support for infrared, ham radio, and bales of laptop-specific crud on a desktop system, to name my three personal favorite useless features. And why have all that lard in the first place? It's fun to build a kernel customized for your CPU and that supports only the hardware and other features that you want it to. You might even see a performance gain.
The Generic Way of Customizing Kernels
You can get freshly-baked kernels and the latest patches from Kernel.org. These are called vanilla kernels because this is where the original, unmodified kernels live. Then you need to assemble your build environment. Both Fedora and Debian make this easy. On Fedora, install the Development Tools package group:
# yum groupinstall 'Development Tools'
You'll also want Qt:
# yum install qt-devel
On Debian use this command:
# aptitude install build-essential libqt3-mt-dev
The Documentation/Changes file in your unpacked source tarball gives you a basic list of applications that you need for a build environment. In fact you should invest a lot of time exploring the documentation that comes in the kernel tarball- there is a wealth of knowledge squirreled away in there.
When you download and unpack your new kernel sources don't put them in /usr/src, and pay no attention to all the people who tell you to do that. Create a directory in your home directory to keep your source trees in. The kernel README itself says:
"...put the kernel tarball in a directory where you have permissions (eg. your home directory)...Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files. They should match the library, and not get messed up by whatever the kernel-du-jour happens to be."
I use /home/carla/kernel.