Kernel patch howto

Patches are created with the diff program. To correctly apply a patch you need to know what base it was generated from and what new version the patch will change the source tree into. These should both be present in the patch file metadata or be possible to deduce from the filename. You apply a patch with the patch program.

The patch program reads a diff or patch file and makes the changes to the source tree described in it. Patches for the Linux kernel are generated relative to the parent directory holding the kernel source dir.

Since this is unlikely to match the name of the kernel source dir on your local machine but is often useful info to see what version an otherwise unlabeled patch was generated against you should change into your kernel source directory and then strip the first element of the path from filenames in the patch file when applying it the -p1 argument to patch does this.

To revert a previously applied patch, use the -R argument to patch. So, if you applied a patch like this:. This as usual with Linux and other UNIX like operating systems can be done in several different ways. In all the examples below I feed the file in uncompressed form to patch via stdin using the following syntax:. Which will leave you with a plain text patch-x. Finally --verbose tells patch to print more information about the work being done.

Checking that the file looks like a valid patch file and checking the code around the bits being modified matches the context provided in the patch are just two of the basic sanity checks patch does. It can either refuse to apply the changes and abort or it can try to find a way to make the patch apply with a few minor changes. This can happen, for example, if the patch makes a change in the middle of the file but for some reasons a few lines have been added or removed near the beginning of the file.

In that case everything looks good it has just moved up or down a bit, and patch will usually adjust the line numbers and apply the patch. If patch stops and presents a File to patch: prompt, then patch could not find a file to be patched. Most likely you forgot to specify -p1 or you are in the wrong directory. The kernel repository holds a lot of objects, making collisions with shorter IDs a real possibility.

Bear in mind that, even if there is no collision with your six-character ID now, that condition may change five years from now. In case your patch fixes a bug, for example, add a tag with a URL referencing the report in the mailing list archives or a bug tracker; if the patch is a result of some earlier mailing list discussion or something documented on the web, point to it.

When linking to mailing list archives, preferably use the lore. To create the link URL, use the contents of the Message-Id header of the message without the surrounding angle brackets. For example:. Please check the link to make sure that it is actually working and points to the relevant message. However, try to make your explanation understandable without external resources.

In addition to giving a URL to a mailing list archive or bug, summarize the relevant points of the discussion that led to the patch as submitted. If your patch fixes a bug in a specific commit, e. The following git config settings can be used to add a pretty format for outputting the above style in the git log or git show commands:.

For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two or more patches. On the other hand, if you make a single change to numerous files, group those changes into a single patch. Thus a single logical change is contained within a single patch. The point to remember is that each patch should make an easily understood change that can be verified by reviewers.

Each patch should be justifiable on its own merits. If one patch depends on another patch in order for a change to be complete, that is OK. When dividing your change into a series of patches, take special care to ensure that the kernel builds and runs properly after each patch in the series.

Developers using git bisect to track down a problem can end up splitting your patch series at any point; they will not thank you if you introduce bugs in the middle. If you cannot condense your patch set into a smaller set of patches, then only post say 15 or so at a time and wait for review and integration.

Check your patch for basic style violations, details of which can be found in Linux kernel coding style. Failure to do so simply wastes the reviewers time and will get your patch rejected, probably without even being read. One significant exception is when moving code from one file to another — in this case you should not modify the moved code at all in the same patch which moves it. This clearly delineates the act of moving the code and your changes. This greatly aids review of the actual differences and allows tools to better track the history of the code itself.

Note, though, that the style checker should be viewed as a guide, not as a replacement for human judgment. If your code looks better with a violation then its probably best left alone. If you cannot find a maintainer for the subsystem you are working on, Andrew Morton akpm linux-foundation. You should also normally choose at least one mailing list to receive a copy of your patch set. Please do not spam unrelated lists, though.

Many kernel-related lists are hosted on vger. There are kernel-related lists hosted elsewhere as well, though. Linus Torvalds is the final arbiter of all changes accepted into the Linux kernel. He gets a lot of e-mail, and, at this point, very few patches go through Linus directly, so typically you should do your best to -avoid- sending him e-mail.

If you have a patch that fixes an exploitable security bug, send that patch to security kernel. For severe bugs, a short embargo may be considered to allow distributors to get the patch out to users; in such cases, obviously, the patch should not be sent to any public lists. See also Security bugs. Patches that fix a severe bug in a released kernel should be directed toward the stable maintainers by putting a line like this:. You should also read Everything you ever wanted to know about Linux -stable releases in addition to this document.

User-space API changes should also be copied to linux-api vger. Linus and other kernel developers need to be able to read and comment on the changes you are submitting.

The easiest way to do this is with git send-email , which is strongly recommended. If you choose not to use git send-email :. Do not attach the patch as a MIME attachment, compressed or not. Many popular e-mail applications will not always transmit a MIME attachment as plain text, making it impossible to comment on your code. See Email clients info for Linux for hints about configuring your e-mail client so that it sends your patches untouched. Your patch will almost certainly get comments from reviewers on ways in which the patch can be improved, in the form of a reply to your email.

You must respond to those comments; ignoring reviewers is a good way to get ignored in return. If you get Reversed or previously applied patch detected!

Assume -R? If you actually did apply this patch previously and you just re-applied it in error, then just say [n]o and abort this patch. If you applied this patch previously and actually intended to revert it, but forgot to specify -R, then you can say [ y ]es here to make patch revert it for you.

This can also happen if the creator of the patch reversed the source and destination directories when creating the patch, and in that case reverting the patch will in fact apply it. Either your download is broken, you tried to feed patch a compressed patch file without uncompressing it first, or the patch file that you are using has been mangled by a mail client or mail transfer agent along the way somewhere, e.

Often these warnings can easily be fixed by joining concatenating the two lines that had been split. As I already mentioned above, these errors should never happen if you apply a patch from kernel. So if you get these errors with kernel. This will let you move from something like 4. The -z flag to interdiff will even let you feed it patches in gzip or bzip2 compressed form directly without the use of zcat or bzcat or manual decompression. Although interdiff may save you a step or two you are generally advised to do the additional steps since interdiff can get things wrong in some cases.

Other nice tools are diffstat, which shows a summary of changes made by a patch; lsdiff, which displays a short listing of affected files in a patch file, along with optionally the line numbers of the start of each patch; and grepdiff, which displays a list of the files modified by a patch where the patch contains a given regular expression. In place of ftp. These are the base stable releases released by Linus.

The highest numbered release is the most recent. If regressions or other serious flaws are found, then a -stable fix patch will be released see below on top of this base.

Once a new 4. To apply a patch moving from 4. Kernels with 3-digit versions are -stable kernels. In your case:. Obviously change the path to the patch or stick it in the same directory. If the source files are owned by root, prefix sudo onto the patch command or run sudo su to become root while you do this. To avoid frustration, you should generally do such things the Ubuntu way. Full instructions using official packages can be found here:. It provides lists of dependencies and step-by-step commands for getting a custom kernel up and running.

By following that procedure, you will end up with an uninstallable package containing your custom kernel, which means that you will be able to switch back to the official kernels in future if needed. The command to type that will apply the patch starts at patch and continues from there. Ubuntu Community Ask! Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams?

Learn more. Correct way to apply patches to your kernel? Ask Question.