This is the first in a series of posts about getting started in Linux kernel development. Most of what is written in this post is already available on the web. It is provided here for completeness and as a pre-amble to the next post in the series.
The aim of this series is to outline one way of getting started with Linux kernel development. It is by no means the only way and it is quite possibly not even the best way.
- You are inherently interested in how the Linux kernel works.
- You know the C programming language well.
- You know how to use git.
This post will describe steps you may take in order to get your first patch merged into the mainline kernel.
Do not submit patches to any part of the kernel outside of drivers/staging whilst getting started with kernel development.
1. Set up your tools
The kernel uses a specific coding style, you may like to configure your editor to support this.
All kernel development is done in the open, this means via mailing lists. Get comfortable with your email client. Do not use HTML when sending email to kernel mailing lists.
Configure git with your email address and name.
[user] email = firstname.lastname@example.org name = Joe Developer
All kernel patches must contain a tag
Signed-off-by: Joe Developer <email@example.com>
You may wish to add to your git config
[format] signOff = true
Pro Tip: If you already have git configured with your GitHub username then add the real name configuration lines to the git config file within your kernel development tree (see task 3 below).
2. Subscribe to mailing lists
Pro Tip: Do not bother subscribing to LKML at this stage.
You may like to sort emails from mailing lists into separate mail boxes. Example regex for sorting;
Pro Tip: Always maintain the complete CC list when responding to email on a kernel mailing list.
3. Set up development tree
Clone Greg Kroah-Hartman’s tree
Set up tracking branch on staging-next (or staging-testing)
At this stage you may like to limit your scope within the kernel tree to the following;
Documentation/process/* drivers/staging/* include/linux/* include/uapi/*
The reasoning is that it is very easy to get overwhelmed while learning a new system as large as the Linux kernel. Limiting scope is one tool useful in controlling the complexity of the task.
4. Fix something
Run checkpatch against drivers in staging until you find a warning that you feel you can fix.
$ scripts/checkpatch.pl -f --terse --strict --show-types drivers/staging/FOO/*.c
Pro Tip: Do not fix line over 80 warnings.
Fix all instances of the warning type within the driver you have chosen. If a job is worth doing it is worth doing properly.
Commit your changes as a single commit, write a correct git log for the commit. Read
Git log messages must be of a specific format and content. At first they are difficult and time consuming to write. You may even find you spend more time writing git logs at first than code. Keep at it, you will learn a lot from doing it thoroughly.
5. Create a patch
At this stage you have created a branch off of staging-next, edited the source and have a single commit containing the changes. The next step is to attempt to eliminate mistakes and then create the patch.
Check the commit is correct
$ git log --color=always --patch --reverse "HEAD~".. | less
Read through the diff, this is what reviewers will see. Make sure the changes are correct and nothing spurious has snuck into your patch.
Your commit should build without warnings. During development you may like to build the driver (without linking it) using
You may also like to build and link the kernel with extra warnings enabled.
make -j9 EXTRA-CFLAGS=-W
Output the patch
$ git format-patch HEAD~ -o path/to/put/patch
Check you patch applies
Kernel development moves fast, another patch may have been merged that touches the same lines of code. Apply and build your patch on the staging-testing branch of Greg Kroah-Hartman’s staging tree.
Pro Tip: Work off of staging-next but make sure your patches apply to staging-testing before you submit them to the driver dev mailing list.
5. Submit the patch
Check the TODO file for whom to send the patch to, or use
$ scripts/get_maintainer.pl XYZ.patch
Submit the patch. You may like to use git
$ git send-email --to='Greg Kroah-Hartman <gregkh@*****.org>' --cc='Joe Maintainer <firstname.lastname@example.org>, driverdev-devel@*****.org' XYZ.patch
It is a good idea to first send the patch to yourself to check you have everything correct.
Respond to feedback. If asked to do so, fix your patch and re-submit.
Pro Tip: Wait at least two weeks before following up on any email sent to a kernel mailing list.
At this stage, if all went successfully, you should get an email from Greg Kroah-Hartman saying that your patch was merged into staging-testing. From here your patch will automatically transition to staging-next then, when the next merge window opens, will by merged into Linus’ mainline.
You should now have a development environment set up suitable for
Linux kernel development. There will of course be further tweaking to
be done, especially in regards to your email setup. You have now seen some the
custom tools used in kernel development, the
contains many more. You should have learned a thing or two from reading the docs in
Documentation/process. Now is probably a good time to read
everything in that directory. Don’t worry if it does not all sink in,
you will need to read, and re-read, the docs many times yet.
Getting your first patch merged into the Linux kernel is an exciting event. Well done if you have got this far, your journey has but started.
Welcome to the Linux kernel and good luck.