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

Call: +44 (0)23 8098 8890
E-mail:

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/checkpatch.pl -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/get_maintainer.pl \

--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 get_maintainer.pl 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 kernel-janitors@vger.kernel.org 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.

Conclusion

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

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
Linux penguin sending an email
Posted 19th June 2020, By Quentin D
In this final part of his blog, Quentin explains the final part of the process: submitting your changes to the Linux Maintainers.
Linux penguin
Posted 5th June 2020, By Quentin D
In his second 'Contributing to the Linux kernel' blog, Quentin looks at finding something to fix, coding and committing changes.
Jenkins for FPGA
Posted 29th May 2020, By Hugh J
FPGA development should be enjoyable but when bugs slip through the net, it can be a headache to find them later on. Hugh looks at a few of the plugins ...more

Latest News

Autumn
Posted 11th September 2020
From adapting to our new working situation to recruiting new staff members and engaging new clients, it’s been a busy summer. Find out more in our latest ...more
Spring 2020
Posted 17th April 2020
Following the beautiful weather over the Easter weekend, we are proud to be able to provide an update on our current activities, showing business is continuing ...more
Business as usual
Posted 20th March 2020
With a strong commitment to keeping our staff and clients safe during this period, we would like to reassure all our business contacts that we remain fully ...more
South Coast Tech Awards Trophy
Posted 6th December 2019
ITDev was excited to attend the first South Coast Technology Awards on Thursday 5th December at the Ageas Bowl. A much needed celebratory awards for a sector ...more