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!
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.
.
