You Really Should Hack Linux

I have a confession to make. I'm an avowed Linux geek, yet I haven't complied the kernel in years. The last time was probably in school when I had to write my own scheduler for the kernel as an assignment, which isn't all that bad when you consider that most people compiling their own kernels are just enabling some obscure driver that they needed. They haven't made Major Modifications to a core piece like The Scheduler. Right? Right? Well, OK, the scheduler wasn't anything to write home about, but it still felt pretty l33t. Anyway, I've decided it's time I delve into the source of Linux again. It's one of the most successful large software projects on the planet, and it's completely open for anyone to dig into. It would be a horribly wasted opportunity for a serious software engineer to miss out on, especially someone interested in nitty-gritty low-level stuff. Even if you aren't interested in OS code or drivers at all, you could study it to learn about tools, coding conventions, documentation techniques, release management processes, debugging techniques, or how to do modularity and configurability, all for a pretty big project. Where else can you get all that for free? Convinced yet? OK then. Off we go.

I'll be using my Ubuntu Hardy Heron machine for development. Conveniently enough, there is a nice little package you can install called linux-kernel-devel which is described thusly:

This is a dummy package that will install all possible packages required to hack comfortably on the kernel.

I don't know about you, but I like to be comfortable when I hack. There is a helpful package included in linux-kernel-devel called kernel-package that makes it easy to create a debian package (.deb) out of our custom kernel, and to do that it's nice to have fakeroot, which allows you to make debian packages without actually being root, so install these two packages like so:

sudo aptitude install linux-kernel-devel fakeroot

It is customary (necessary?) to put your Linux source code in the /usr/src directory. Astute readers will notice that this directory is owned by root, but users in the src group can write there too. To avoid doing too much as root, add yourself to the src group like so:

sudo adduser <username> src

You'll need to log out and log back in (or start a new login shell, or maybe you can simply newgrp src) for the change to take effect. Test that you can create a file in /usr/src with a touch newfile command in that directory. Did it work? Sweet.

Now it's time to download some source code. The kernel is kept under revision control with git. There are other ways to get the source, but if you want the full kernel hacking experience, clone Linus' git repository in /usr/src like so:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6

This will probably take a while (I told you this was no toy project!). Once you've done that you can stay up-to-date by running git pull in the linux-2.6 directory.

Before we make a change, let's create our own branch to work off of. In the linux-2.6 directory run

git checkout -b my-cool-branch

Choose a better branch name then that. This will create the branch and make it current. Type git branch to see which branches you have and which one is current. OK, now we can make sure that the kernel will build (a good idea to do before you go making changes to the code). Before you build though, you need to configure your kernel. There are an amazing number of configuration options for the kernel. You can see these by running make xconfig (if it doesn't work, try installing libqt3-headers first, or maybe you only need qt3-dev-tools and libqt3-mt-dev, sorry, I didn't test that very well). Pretty overwhelming at first. An easier thing to try at first is to re-use the configuration for the currently running kernel. On Ubuntu (and Debian) the configurations for installed kernels are found in /boot/config-*. Copy the config for the currently running kernel like this: 

cp /boot/config-`uname -r` .config

Then run

make xconfig

to see what is in that configuration and tweak it if desired (I wouldn't yet). Once you are happy with your configuration, save and exit xconfig. Now it's time to start building. Well almost. First make sure we are starting out clean. This is where we start doing everything as "fakeroot," and we use the make-kpkg command instead of make itself (read their man pages for more information). OK, clean:

fakeroot make-kpkg clean

That should have been fairly quick. Now the big command:

fakeroot make-kpkg --revision=1 --append-to-version=mycustomkernel --initrd kernel_image kernel_headers

Time to sit back and watch compiler messages fly by. This will take a while (it took 104 minutes on my kvm ubuntu virtual machine). When it finishes, you will have a nice .deb package of your new kernel and its modules in your /usr/src directory. From anywhere you can now type this to install it:

sudo dpkg -i /usr/src/linux-image-2.6.26-rc5mycustomkernel_1_i386.deb

(Obviously the filename will vary depending on which version you are based off of and what options you fed to make-kpkg for --revision and --append-to-version). Now reboot and see if it runs!

OK, I think that's enough for one blog entry. I cover actually making a change to some kernel code in another entry. I'll just close with a list of good references that I used in getting this done.

References:

Comments

Dominicleung said…
Thaank you for sharing this
September 27, 2023 at 8:22 AM
Post a Comment

Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either. I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor. OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this: module top; task do_stuff ( int wait_time); #wait_time $display ( "waited %0d, then did stuff" , wa
Read more

'git revert' Is Not Equivalent To 'svn revert'

I just learned that if you have some changes in your working tree that you want to get rid of, you don't type 'git revert' like you might guess. No, that's what cvs, subversion, mercurial, and bazaar (to name a few) use revert to mean, but not git. With git, revert is used to undo actual commits. Thankfully, you can undo your revert with another 'git revert', I just learned. So let me repeat to be clear, if you have changes to your working files that you want to abandon, DO NOT do this: git revert HEAD That will undo your last commit. Do this instead: git reset --hard HEAD I'm glad I have that straightened out now. I'm wondering if /etc was really a good place for me to start out playing with git. UPDATE: Nearly two years later and I'm still getting comments on this. I'm glad I've been able to help people out this way. The discussion in the comments is good, and one thing I'd like to point out is that I now always use
Read more

Git Rebase Explained

Image
Introduction Rebase is a helpful git command that can be used to turn a branchy two-headed version history into an easy to follow linear one. A linear history is much easier for a human eye to follow and a human brain to understand. Rebase is a very safe command to use, despite some fear that people have about it. This post should explain how rebase works and clear up any misunderstandings about it. Rebase Basics The short summary of rebase is that it cuts commits out of the git history and reconnects them somewhere else. Let's say the common scenario comes up: you commit a change to the main branch of a repository, you then run  git fetch , and in come a couple changes that other people made on the main branch. If your commit is version 46f and the others that just came in on the fetch are versions ef9 and 4a2, your version history might look like this: The main branch now has two heads, 46f and 4a2. You can run  git rebase  to disconnect your commit from version d88 and connect i
Read more