

Related Topics: Linux Containers

Linux Containers: Article

Kernel source merging 101

How to play Linus Torvalds and update the Linux kernel yourself

(LinuxWorld) -- If you're not familiar with the kernel patch and development process, here it is in a nutshell. People modify source files to fix bugs, add or remove features, or adapt to changes in the way the kernel handles certain tasks. They produce patch files by using a utility called diff. diff compares the old source file to the new one and produces a text file from the differences. You can then distribute this text file to others, who can use it to patch their source code with the utility called (what else?) patch.

Incidentally, the tradition for using patch to produce kernel patch files is to add the command line switches -urN, which tells diff to use the unified output format (which is what everyone on the kernel development team uses), recurse through directories, and keep track of new files that appear in one branch but not another. The full command would be diff -Nru.

Until recently, kernel developers submitted their patch files by including them within the body of an email message. Then they sent the message to one or more kernel maintainers and/or the kernel development mailing list. I'm not quite sure how the patch submission process will change now that Linus Torvalds and others are using the Bitkeeper Web-based source management system, but it looks like they'll still rely largely on the diff

Linus or one of the other kernel maintainers merge the various patches into the kernel source tree, make other changes, and then release a collection of patches in one large text file, which is compressed for faster downloads. If you want to apply the patches, you download the file and apply it to the correct version of the kernel source code.

I don't know how others do this, but I keep kernel versions in directories like /usr/src/linux-2.4.18-pre8 to identify the kernel version for that source tree. Then I download the latest patches to the /usr/src directory. For example, I downloaded the Michael Cohen patch file patch-2.4.18-pre8-mjc.bz2 and put it in /usr/src. If I wanted to apply the Michael Cohen patch as is, I would then change to the /usr/src/linux-2.4.18-pre8 directory and run the command:

# bzcat ../patch-2.4.18-pre8-mjc.bz2 | patch -p1 -E --dry-run

Don't type the pound sign (#) - it's the part of the prompt that usually tells you you're logged in as the root user.

The -p1 switch tells patch to ignore the first level of directories in the patch file. This can be important, because the maintainers all seem to use their own conventions for the root directory for the kernel source tree, and that directory name gets included in the patch file. For example, if someone keeps the old kernel source in /usr/src/oldkernel and the modified source in /usr/src/newkernel, then the patch file will contain the two directory names oldkernel and newkernel. If you use the switch -p0, patch will expect to find the newkernel directory name on your system as part of the full path name (for example, newkernel/drivers/ide/ide-dma.c). If, like me, you named the top directory of the kernel tree something like linux-2.4.18-pre8, patch will fail. The -p1 switch tells it to ignore that top level and go straight to drivers/ide/ide-dma.c.

The -E switch tells patch to go ahead and delete any files that shouldn't exist after the patch. These are generally files that the maintainer moved to another location or deleted because they were no longer needed.

The --dry-run portion of the command tells patch to pretend to apply the patches without actually changing anything. I do this out of habit because it prevents me from making stupid mistakes like changing to the wrong kernel tree before applying the patch. If the patch process produces many error messages, I know I've probably done something wrong. If it looks like everything patched ok, then I run the command again, only for real. That "for real" command is just the same command without the --dry-run:


The challenge

The 2.5 branch is still in too transitory a state to tackle with any confidence, so I started with linux-2.4.18-pre8. I figured I'd better take it slow. I've led a rather sedentary lifestyle when it comes to examining the kernel source, so I didn't want to break into a sprint on the first go and risk a heart attack. In other words, I wanted to merge only a handful of changes, not 50 at a shot the way Linus and others do.

I noticed that Michael Cohen had released a large patch against 2.4.18-pre8 that included many interesting features. It merges the code to handle hardware health sensors (so you can view things like the fan speed on your motherboard). It also adds code to make the kernel preemptive. It has other performance enhancing modifications to the kernel and includes several fixes that weren't in the 2.4 branch at the time Cohen posted his patch, such as fixes to the Reiserfs file system.

Thibaut Laurent posted on the kernel development mailing list that there was a minor problem with the file timer.c in Cohen's patch. Thomas Hood pointed out that Cohen's updates to the plug-and-play BIOS code were out of date. Paul P Komkoff Jr posted a set of patches that adds new capabilities for IP net filtering. Finally, I like to add a line to drivers/acpi/hardware/hwsleep.c to force the kernel to shut off the machine. This is not a patch for general use. I only include it because the funky ACPI BIOS tables in ASUS motherboards keep me from being able to shut off my system with the halt command.

I figured it would be a good lesson in patch management if I could apply all of the above fixes and additions to Michael Cohen's patch and produce my own patch from the result.

I downloaded the latest PnP BIOS code for 2.4.18-pre8 by Thomas Hood and began the grunt work of replacing the PnP portions of Cohen's patch with the latest code. The job was tedious, but it was easy because both Cohen's patch and Hood's patch are applied against the same kernel version (2.4.18-pre8). So all I really had to do was find all the sections of Cohen's patch that corresponded to Hood's and make the swap. It was even easier to apply the net filter additions, timer.c fix, and my shutdown kludge.

The result is patch-2.4.18-pre8-np.gz, which you can find at the download section of www.varlinux.org. I'm using that kernel right now, but things are moving so quickly it will probably be well out of date by the time you read this. There's already a linux-2.4.18-pre9 available as I write this and pre9 includes some of the same fixes you'll find in my patch. (It lacks all the added features, however, such as the net filter code, preemptive kernel, etc.)

What's the big deal about merging patches? It was only easy for me because I chose to work with a stable branch of the kernel and patches that were supposed to be applied against the same kernel version.

I tackled the 2.5.4-pre3 kernel source just to see what the differences would be like if I used an unstable branch. I didn't even have to look for patches to apply. It wouldn't compile on my system as is. It broke on ide-dma.c, ide-scsi.c, sg.c, and in other places. I couldn't find any fixes for these problems so I started scanning the code to see if I could fix it myself.

That's when I realized what this kernel development process really needs -- an editor with an integrated cross-reference and source code analysis system.

Perhaps people like Linus Torvalds doesn't need such a program because he knows where every instance of a variable appears in the source tree (I doubt it, since so many of his patches lately leave many files with legacy variables and structures unpatched to work with updates to other parts of the kernel source tree). Alternatively, perhaps he and others have some neat command-line utilities that do the job. I'm not an emacs user, so for all I know emacs has these capabilities (I have no idea if Linus uses emacs anyway).

However, I would want something more powerful than a multi-file editor for a job like this. So I searched Freshmeat and found a few snazzy products that analyze source code, cross reference the source, and let you perform recursive updates in ways that help prevent disaster. Some run on Linux, so I plan to play with one or two.

I'll get back to you on them when I've had time to learn how well they work. In the meantime, unless you're a kernel guru, stay away from the 2.5 branch. Stick to the easy stuff, like I do. Your heart will thank you for it.

More Stories By Nicholas Petreley

Nicholas Petreley is a computer consultant and author in Asheville, NC.

Comments (0)

Share your thoughts on this story.

Add your comment


@ThingsExpo Stories