From Fedora Project Wiki


This is designed to be a guide to submitting patches to the Fedora kernel. The Fedora kernel is different from the upstream kernel although some practices will be referenced. Many of the commands here are just examples. You may find other commands that do something better (feel free to edit this wiki)

Getting Source Code

The Fedora kernel uses standard Fedora packaging tools. These are the easiest way to interact with the Fedora kernel. The base set to get started with the kernel are documented Building_a_custom_kernel here. Once those are installed, the tree can be cloned using fedpkg

$ fedpkg clone -a kernel

Once that is cloned, edit .git/config in your newly cloned kernel directory. You may see the lines

        to =

Change the e-mail to ''. This will ensure it gets sent to the proper lists.

Setting up your e-mail

The easiest way for maintainers to review patches is if they are in the body of the e-mail itself. The easiest way to do this is to use git-send-email. Trying to copy/paste patches into the body of an e-mail is error prone. If you don't want to set up git-send-email, sending patches as an attachment is preferred.

There are many good tutorials available on the web. A sample .gitconfig is shown below

        smtpEncryption = tls
        smtpServer =
        smtpUser =
        smtpserverport = 587
        smtppass = hunter2

Note that gmail with Two Factor Authentication may require setup outside the scope of this document

Git branch basics

The kernel newbies has a great introduction to git basics. The Fedora kernel tree has a separate branch for each fedora release. In general, you want to be making changes to rawhide which is the master branch. It's best to have a separate branch for each patch series e.g.

$ git checkout -b rhbz_1234 origin/master
<do some stuff>
$ git checkout -b rhbz_5678 origin/master

Learning how to use git will serve you well in the long term

Building the kernel

Please remember to test your changes before sending them out. You will want to at least do

$ fedpkg prep

to verify the patch applies.

Making a change

Again, kernel newbies has a great tutorial. Typically, you'll modify the kernel.spec

$ git status
On branch my_test_branch
Your branch is up-to-date with 'origin/f24'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   kernel.spec

no changes added to commit (use "git add" and/or "git commit -a")

Now the changes need to be committed.

$ git commit -a

You'll want to add a useful commit message. This should _not_ just be a description of what is changed. The reviewers can read that in the code. It is more important to explain _why_ this change is being made. Is it a new feature? fixing a bug? making code more useful?

Generating a patch

Once you have a commit in your git tree, you need to generate a patch file. It's always good to verify the commit looks correct with git

$ git show HEAD

Double check one last time, is everything to your liking? Are all files added? Once it looks good use git-format-patch to generate a patch

$ git format-patch -1 HEAD

This will generate a file in the current directory. It's good practice to make sure the patch applies to the branch before sending it out

$ git checkout -b test_branch origin/master

$ git am -3 path-to-my-patch.patch

If successful it should say applied and you should see the patch in your git log. If you get errors, double check the git tree where you generated the patch

Sending a patch

All patches should be sent to the Fedora kernel mailing list

$ git send-email --to path-to-my-patch.patch