The Illustrated Guide to Linux First Patch
Step 1: Standards and practices
Everything you have to know for working on the Linux Kernel has been created by Linus Torvalds. That is the Linux Kernel itself and git.
Oh.. almost everything. Linus seemed content with the C programming language.
Linux kernel is currently under a mixture of code following C89/C90 and C99 standards. By taking a look into the Makefiles you’ll find the majority compiling with -std=gnu89, that is to say they are using the C89/C90 standard with some extensions.
If you ever wonder why they still allow errors like these “error: ‘for’ loop initial declarations are only allowed in C99 mode” Linus has given a legitimate answer which says that it’s mainly a standard for keeping code clean and easy to follw through the sources.
Why git? CVS and SVN seemd a terrible idea at that time as a version control system and what do you do when you really don’t like a tool? That’s right, you’ve probably guessed.
So, the step 0 would be to setup git and download the latest kernel version. Also,make sure to fetch the changes every time you start working on something, so that your patches won’t be rejected when the maintainer tries to apply them on the tree.
The next step would be to check the kernel coding style, which is generously explained in the Linux Documentation and set your editor according to them.
Yes, apart from the ultimate error which is breaking the build, the second ultimate would be mixing tabs and spaces! Linux Kernel goes on the dark side of tabs (no cookies, sorry), with extra-spaces when aligning parameters.
Step 2: My code is compiling
Depending on your processor, the building time might vary, but it will still take a bit. In the meantime you can read Linux Device Drivers or have a little bit of fun reading some statistics on how many times words like ‘bastard’ and ‘crap’ appear in the Linux Kernel source code. You can also grep it for more fun.
Step 3: Make a small change and send it
The reason for which you that to pass through all these preparatory steps was to finally get some changes committed. You can start with a simple change such as adding error check on some devices or clean some code that needs refactoring.
Linux does not use pull requests (at least not on github )
as a means of merging changes, but e-mailed patches. That means you have to find the propper maintainter - the get_maintainter.pl in the
/scripts folder will help you to do so - and e-mail him your patch. You’ll find a set of standards for that, too.
Just keep in mind to compile your module and test after making even the tiniest change, because if something goes wrong you will have wasted your time and the maintainer’s time on sending a patch that cannot be applied, or worse, breaks the build.
Even if sometimes paying attention to all these rules involving proper coding, commit standards and e-mail formatting seems to be a little bit overwhelming by taking more time than the actual code changes, with time it will become quite natural. After all, in a development area of aproximately 1,500 people working from remote areas, the needs of having a rather fixed set of rules is indeed well-justified.
Step 4: Become a regular contributor
After sending a series of first patches, you’ll be proud to be officially known as a Kernel Newbie! You can choose a project to focus on, talk to people in the community, hang out on the IRC channels and so on.
Keep in mind that, if there’s something you cannot manage, it is very likely to find someone on the IRC channels more than happy to give you a hand. You don’t have to become like this guy!
For an official tutorial, please follow this link.
Copyright on the images goes to https://xkcd.com, if not specified otherwise.