A checklist for submitting your first Linux kernel patch

One of the biggest—and the fastest moving—open source projects, the Linux kernel, is composed of about 53,600 files and nearly 20-million lines of code. With more than 15,600 programmers contributing to the project worldwide, the Linux kernel follows a maintainer model for collaboration.

In this article, I'll provide a quick checklist of steps involved with making your first kernel contribution, and look at what you should know before submitting a patch. For a more in-depth look at the submission process for contributing your first patch, read the KernelNewbies First Kernel Patch tutorial .

Contributing to the kernel

Step 1: Prepare your system.

Steps in this article assume you have the following tools on your system:

• Text editor
• Email client
• Version control system (e.g.,git)

Step 2: Download the Linux kernel code repository :

git clone -b staging-testing

Copy your current config:

cp /boot/config-`uname -r`* .config

Step 3: Build/install your kernel.

make -jX

Step 4: Make a branch and switch to it.

git checkout -b first-patch

Step 5: Update your kernel to point to the latest code base.

git fetch origin

Step 6: Make a change to the code base.

Recompile using make command to ensure that your change does not produce errors.

Step 7: Commit your changes and create a patch.

git add <file>

git commit -s -v

git format-patch -o /tmp/ HEAD^

The subject consists of the path to the file name separated by colons, followed by what the patch does in the imperative tense. After a blank line comes the description of the patch and the mandatory signed off tag and, lastly, a diff of your patch.

Here is another example of a simple patch:

Next, send the patch using email from the command line (in this case, Mutt):

mutt -H /tmp/0001-<whatever your filename is>

To know the list of maintainers to whom to send the patch, use the get_maintainer.pl script

.

What to know before submitting your first patch

• Greg Kroah-Hartman 's staging tree is a good place to submit your first patch as he accepts easy patches from new contributors. When you get familiar with the patch-sending process, you could send subsystem-specific patches with increased complexity.
• You also could start with correcting coding style issues in the code. To learn more, read the Linux kernel coding style documentation .
• The script checkpatch.pl detects coding style errors for you. For example, run:

  perl scripts/checkpatch.pl -f drivers/staging/android/* | less

• You could complete TODOs left incomplete by developers:

  find drivers/staging -name TODO 

• Coccinelle is a helpful tool for pattern matching.
• Read the kernel mailing archives .
• Go through the linux.git log to see commits by previous authors for inspiration.

• Note: Do not top-post to communicate with the reviewer of your patch! Here's an example:

  Wrong way:

  Chris,
  Yes let’s schedule the meeting tomorrow, on the second floor.
  > On Fri, Apr 26, 2013 at 9:25 AM, Chris wrote:
  > Hey John, I had some questions:
  > 1. Do you want to schedule the meeting tomorrow?
  > 2. On which floor in the office?
  

  > 3. What time is suitable to you?

  (Notice that the last question was unintentionally left unanswered in the reply.)

  Correct way:

  Chris,
  See my answers below...
  > On Fri, Apr 26, 2013 at 9:25 AM, Chris wrote:
  > Hey John, I had some questions:
  > 1. Do you want to schedule the meeting tomorrow?
  Yes tomorrow is fine.
  > 2. On which floor in the office?
  Let's keep it on the second floor.
  > 3. What time is suitable to you?
  09:00 am would be alright.

  (All questions were answered, and this way saves reading time.)

• The Eudyptula challenge is a great way to learn kernel basics.

To learn more, read the KernelNewbies First Kernel Patch tutorial . After that, if you still have any questions, ask on the kernelnewbies mailing list or in the #kernelnewbies IRC channel .