I look at it as a great chance for learning.
It's Open Source. Get the source code, check out one of the innumerable online tutorials, and give it a shot. That is, if the source isn't available in your distribution of choice (Debian has it, of course) already with all the bells and whistles preselected.
The first time one tries "$ make menuconfig", it's a mind-numbing number of options, drivers, things to be compiled in and things to be built as modules for loading if, and only if, needed.
Taking your distributions pre-configured kernel source, and changing only those few things that you wish to play with, is the best way to jump in. Most distributions compile for the basic x86-686 processor, which will run on most anything the people reading this blog would use. But if you have an AMD, or a newer Intel, customizing to your particular hardware can be a great excuse to play at compiling your own kernel.
Even in a modern car, you and I may not be able to tune them any more, but we can still change the oil and spark plugs for that "this is mine" feeling.
Now it may very well be that only seriously dedicated supercomputer users will notice any difference between the pre-packaged kernel that comes with every distribution and one which is compiled to the particular CPU, memory requirements, minimal drivers, and such. I can honestly say I've never noticed any speed-up.
I first compiled Linux 2.2.19 because my boss at the time wanted his server running with the latest vanilla kernel. (The vanilla kernel is the name given to what is downloaded from Kernel.org, rather than taking what comes with the distribution.)
Then, in 2003 when I owned a Sony Vaio laptop, the wifi card that came in it had one digit out of place. It was custom for Sony in just that way, but it made it so the stock kernel driver didn't recognize it.
During the time it took for the fix to make it into the stock kernel, I edited the driver source code, changed a "2" to a "3", and then built the kernel for myself.
Even today, I have an HP laptop with an nVidia GPU, and there's just something about the Debian kernel, the nVidia driver, and that particular video card, that doesn't quite work right. But it's running a vanilla Linux 3.4.42 right now, and that works just fine.
Except for that one laptop, I just compile kernels for the fun of it.
Merely because I can.
But I meant this to be a post about learning.
Even with all the many thousands of people who compile the vanilla kernels, the distribution packagers, the corporate cattle, and the people like me who are just interested amateurs, there still remains something that troubles me:
Compiler Warnings. Like this:
drivers/isdn/gigaset/capi.c:309:20: warning: ‘format_ie’ defined but not used [-Wunused-function]
There are several dozen such errors, mismatched variables, unused and/or undeclared, cluttering up the output. And these are easy fixes. There's no grand scheme to worry about, no change in logic flow or style, just a declaration where there wasn't one, or the commending out of a variable declaration that isn't used.
Greg Kroah Hartman's wonderful talk on the development cycle of the Linux kernel:
In it, Greg talks about the number of patch submissions by organization and individual, way down to where individual people are submitting one patch (like I did), and he points to a contributor who is sending in spelling fixes.
Wouldn't fixing compiler warnings be a great way to learn what is going on, practice C, or in my case assembler, perhaps in a programming class? Isn't this an excellent real-world example to be used for teaching and learning, even if the changes are never submitted?
Or even better, if they are submitted (after being tested, of course)?
I can say from my own experience that even though I stumbled through my one and only patch submitted to the Linux Kernel Mailing List, I received consideration and assistance from the members of the list in doing it the right way. What more could a student ask for?
To help out compiling your own, here's my recipe:
- Download the kernel you want to /usr/src and uncompress it, tar -xf linux-3.8.10.tar.xz
- cd /usr/src/linux-3.8.10
- cp /boot/config-whatever-is-latest ./.config
- make menuconfig This will give you the horrible list of options seen in the graphic captured above. Don't let that scare you. Browse around, make what changes you want
- Even if you change nothing, save when you exit!
- make modules
- make install
- make modules install
- $ make -j 2 KDEB_PKGVERSION=1.custom deb-pkg
So there you go. Don't fear the command line! Don't fear the kernel! Dive in, try things. Just don't delete the kernel that came installed with your distribution, and the worst thing that could happen is to have to reboot back into that and delete the new one.
And that's not so hard.
Update: Something I found out that you should know.
Once you're done installing your kernel, and it's working, be sure to to back into the build directory, /usr/src and issue the following command:
- $ make clean
Deleting the used .deb files is fine too, once you're satisfied that everything is running to your satisfaction.