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

VPK120 development board pictured wearing ear defenders with silent smiley on the fan
Posted 13th June 2023, By Aysa D
This blog contains the final steps for adding the minimal IP to send the necessary SYSMON data to the System Controller for controlling the fan on the AMD ...more
VPK120 development board pictured wearing ear defenders
Posted 25th May 2023, By Aysa D
Whilst developing on an AMD Versal VPK120 you will want to control the fan speed to keep the noise at manageable levels. This guide captures the steps taken to ...more
Robin on a bird table
Posted 20th January 2023, By Andy C
The customer is always right, and he hasn't changed his requirements, but the consultant says they're in constant flux. Who's right? Let's explore further ...
JonO interviewing Matthew
Posted 30th June 2022, By Jon O
30th June and it's Matthew's 2 year anniversary of joining as a full-time member of staff. Matthew spent 2 summers working for us as an intern before joining ...more

Latest News

Posted 12th September 2023
ITDev is proud to announce the launch of a new FPGA video IP core. The core allows integrators to quickly and easily add high-quality colour space conversion ...more
Shot of Sydney Harbour Bridge
Posted 3rd March 2023
We welcome David back from Australia and review some of the actvities we've been engaged with in February 2023.
Posted 9th August 2022
Last month we attended the second TechNES FPGA Frontrunners event, here's our write up from the day ...
Posted 28th July 2022
Here's a short report on our attendance at the ECS Taster week Careers Fair On Tues 26th July. A chance to promote industrial opportunties to year 11 students ...more