• Choose a category
• All
• Classic-Fiction

The “in progress” group. Patches that are actively being developed, and should not be submitted anywhere yet.

The “backport” group. Patches that adapt the source tree to older versions of the kernel tree.

The “do not ship” group. Patches that for some reason should never be submitted upstream. For example, one such patch might change embedded driver identification strings to make it easier to distinguish, in the field, between an out-of-tree version of the driver and a version shipped by a distribution vendor.

Now to discuss the reasons for ordering groups of patches in this way. We would like the lowest patches in the stack to be as stable as possible, so that we will not need to rework higher patches due to changes in context. Putting patches that will never be changed first in the series file serves this purpose.

We would also like the patches that we know we’ll need to modify to be applied on top of a source tree that resembles the upstream tree as closely as possible. This is why we keep accepted patches around for a while.

The “backport” and “do not ship” patches float at the end of the series file. The backport patches must be applied on top of all other patches, and the “do not ship” patches might as well stay out of harm’s way.

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 a good backport patch is to make your code look as if it were written for the older version of the kernel you’re targeting. The less obtrusive the patch, the easier it will be to understand and maintain. If you’re writing a collection of backport patches to avoid the “rat’s nest” effect of multilple #ifdefs (hunks of source code that are only used conditionally) in your code, don’t introduce version-dependent #ifdefs into the patches. Instead, write several patches, each of which makes unconditional changes, and control their application using guards.

There are two reasons to divide backport patches into a distinct group, away from the “regular” patches whose effects they modify. The first is that intermingling the two makes it more difficult to use a tool like the patchbomb extension to automate the process of submitting the patches to an upstream maintainer. The second is that a backport patch could disturb the context in which a subsequent regular patch is applied, making it impossible to apply the regular patch cleanly without the earlier backport patch already being applied.

Useful Tips for Developing with MQ

Organizing Patches in Directories

If you’re working on a substantial project with MQ, it