Get your patch merged: a journey into the Linux kernel – Part 3

Call: +44 (0)23 8098 8890

Posted 19th June 2020, By Quentin D
Linux penguin sending an email

Introduction to Part 3

Here we are at the end of our long journey. We’ve successfully configured our tools, cloned the proper Linux repository, found something to work on and committed these changes. We can be proud of ourselves! But let’s not forget that to make all our work worthwhile, we need to submit our changes to the Linux maintainers!

This blog will be slightly shorter than the previous ones, but it's the most important one ;)

Without any further ado, let's dive in!

Dive gif

Submitting a patch, the last leap

Although patch submission is not a big step to take, it's not the easiest one. As the maintainers receive a huge amount of emails (8.5 changes per hour on average for the kernel in 2017; that means 8.5 changes, each hour of the day, each day of the year) a set of rules has been defined to ensure efficient communication. It seems a bit hard at first but you'll soon get used to it!

Create the patch

First, we'll ensure our patch follows Linux's coding style by testing our latest commit's changes with checkpatch:

scripts/ -g HEAD

Any warning introduced by your work has to be fixed before submission. Also, if checkpatch issues a warning for a line you haven't changed...fix it anyway!

Now we'll create the patch. The best tool for this is obviously Git as it will create a nice patch, which will appear in an email format, so all you have to do is send it!

git format-patch -o /tmp HEAD^

This command will create a patch from the latest Git commit and will write it to a file inside /tmp; change this output folder so it appears where you want it to.

If you look at the generated patch, you'll find a subject, from field with your name (your Git credentials); and a date field... Also, if this is a modified version of a previous patch, you can append -vX where X is your patch version (if you do not understand what this means, just assume you're not at this step yet).

... and send the patch!

Now, send the patch! You could use Mutt here but using Mutt to send patches is not a simple process and since we configured git send-email command... Let's use it!

git send-email --cc-cmd='./scripts/ \

--norolestats /tmp/<PATCH>' --cc <your email address> /tmp/<PATCH>

What does all this mean? First, git send-email is a Git command to send... an email. The last argument to this command (/tmp/<PATCH>) is the path to your email's body: your patch file.

--cc is an address you want to add as copy. It's useful to add yourself on copy because if you subscribe to a lot of mailing list, this is a clever way to filter which emails are aimed to you (as you're on copy) and which are aimed at everyone (they're aimed to the mailing list and not directly you).

--cc-cmd is a command that's used by Git to fill the cc field of your email. Here we want to use the script in order to list all the maintainers related to the lines which you've changed in your patch. It's a very convenient way to find everyone who's concerned by your changes!

If your changes are related to a spelling mistake or a warning fix: add to your mail's cc field. This mailing list is full of people who want to start contributing to the Linux kernel with some small fixes. This is a nice way to find people who could help you understand what's right / wrong in your patch submission process.

Last advice: before sending your email, use Git's --dry-run switch. This will go through all the email-sending process without really sending it. So, you can check your email's content, who it will be sent to, the subject etc.

And now, we wait

Now all that remains is to wait for answers / remarks / comments on your code. If someone does not understand what you've done, explain it. If a reviewer or maintainer asks for a modification: see how it fits relative to the entire kernel, ask for clarifications and make sure you understand what they mean. It's important that they see you as 'the trusted maintainer of your own code'.

It’s in this final step that Mutt will be useful. It’s more convenient to use Mutt than other email clients, especially as it’s now properly configured to send mails to the Linux mailing-lists.

Maintainers are busy peoples so if you do not receive any replies or feedback for a few days, no rush. After a week, ensure you've followed all the rules of the kernel's communication and send the patch again or (gently) ping the maintainer. For a big patch series, wait a bit longer.


That was a very long journey, wasn't it? If your patch was successfully merged, congratulations! It's an important step to get your first patch merged, but it won't make you a ‘rockstar’ developer (sorry). Now you need to learn more about the kernel's internals, the more you learn, the more you'll be able to submit meaningful patches!

However, if your patch wasn't merged, we've all been there so don't worry. I've always thought that failure is not a problem, but a lack of progress is. So, if you learn, as you progress, you can be sure that you'll achieve your goals one day. Thus, read a bit more about the kernel, maybe some other guides too, so you have a few different points of view regarding patch submission.

How ITDev Can Help

As a provider of software and electronics design services, we are often working with Linux and Android operating systems. We have extensive experience in developing, modifying, building, debugging and bring up of these operating systems, be it for new developments or working with existing kernels to demonstrate new device technologies and features.

We offer advice and assistance to companies considering to use or already using Linux or Android on their embedded system. Initial discussions are always free of charge, so if you have any questions, or would like to find out more, email us or call us on +44 (0)23 8098 8890.

Embedded Linux workshop

We are investigating the possibility of running an 'online' workshop focused on the challenges around embedded Linux later this year. If you would be interested in attending a 'virtual' workshop, sign up to our Embedded Linux Interest Group to be kept informed.



IET Enterprise Partners logo

Latest Blog Posts

Our product development process
Posted 24th September 2021, By Steve W
In his first in a series of blogs addressing the product development process, Steve looks at how to avoid the pitfalls ...
An empty office and desserted Science Park
Posted 29th January 2021, By Jon O
Having started 2021 much as we ended 2020, we thought it would be good to look back to before the pandemic and reflect on how the year turned out against ...more
Higher level testbench reusing lower level components
Posted 5th January 2021, By Tom J
ITDev recently engaged with an ASIC design company. This blog outlines our verification strategy, and how our knowledge of UVM allowed us to achieve high test ...more
Ladybug in sight
Posted 3rd August 2020, By James H
If debugging a Linux driver is bugging you, this 'how to' guide explains how to approach this using the function tracer within ftrace to find out what’s going ...more

Latest News

Variety is the spice of life
Posted 15th July 2021
The newly re-modeled cafe on the Science Park has put us in a culinary mood but keep on reading and you'll see there's another reason why we chose a spice rack ...more
Supply chain management
Posted 7th June 2021
Recent activities in May include focusing on a number of product development enquiries, helping an aerospace client with support issues and starting ...more
Deep tech
Posted 10th May 2021
News this month includes details of further engagement with our client on Android audio device driver development and a new partnership with the world’s first ...more
SKA at night
Posted 31st March 2021
As our work tends to focus on ‘technologies’ rather than ‘markets’, it’s normal for our portfolio of projects to cover a range of industries.