Maintaining the Patch Series

In my work, I use a number of guards to control which patches are to be applied:

  • Accepted patches are guarded with accepted. I enable this guard most of the time. When I’m applying the patches on top of a tree where the patches are already present, I can turn this patch off, and the patches that follow it will apply cleanly.

  • Patches that are finished, but not yet submitted, have no guards. If I’m applying the patch stack to a copy of the upstream tree, I don’t need to enable any guards in order to get a reasonably safe source tree.

  • Those patches that need reworking before being resubmitted are guarded with rework.

  • For those patches that are still under development, I use devel.

  • A backport patch may have several guards, one for each version of the kernel to which it applies. For example, a patch that backports a piece of code to 2.6.9 will have a 2.6.9 guard.

This variety of guards gives me considerable flexibility in determining what kind of source tree I want to end up with. For most situations, the selection of appropriate guards is automated during the build process, but I can manually tune the guards to use for less common circumstances.

The Art of Writing Backport Patches

Using MQ, writing a backport patch is a simple process. All such a patch has to do is modify a piece of code that uses a kernel feature not present in the older version of the kernel, so that the driver continues to work correctly under that older version.

A useful goal when writing ...

Get Mercurial: The Definitive Guide now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.