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.