Right, so you want to contribute to the Linux kernel. Fantastic. You’ve written some code, fixed a bug, maybe even added a shiny new driver. Now comes the fun part: getting that code accepted. Forget GitHub pull requests and fancy web interfaces. Here, we do things the old way, the hard way, and frankly, the right way for a project of this scale and seriousness. We use email. Lots of it.

The entire process revolves around the Linux Kernel Mailing List (LKML). This is the main artery of kernel development, a firehose of technical discussion, heated debate, and patches flying back and forth. Subscribing to it is like trying to drink from that firehose; you’ll mostly just get waterboarded by a constant stream of 500+ emails a day. I don’t recommend it for the faint of heart. Your goal is to send a perfectly formatted patch into this maelstrom and have it noticed for the right reasons.

Your Toolchain: Git and git send-email

You’ll live and die by git. The first step is to craft your patch. You make your changes, commit them with a good commit message (more on that in a second), and then you need to export it as a patch file. But we don’t just git format-patch and attach it to an email like a caveman. We use git send-email. This tool is the gatekeeper; it formats everything exactly how the senior developers expect to see it.

Getting git send-email working is often the first and most absurd hurdle. It requires a working SMTP setup. On Ubuntu/Debian, you need to install the specific package and its friends:

sudo apt-get install git-email libio-socket-ssl-perl libnet-ssleay-perl

Now, configure your ~/.gitconfig to know how to talk to your email provider. This isn’t a mere suggestion; it’s mandatory.

[sendemail]
  smtpServer = smtp.gmail.com
  smtpServerPort = 587
  smtpEncryption = tls
  smtpUser = your.name@gmail.com
  from = Your Name <your.name@gmail.com>
  confirm = always

Yes, you’ll probably have to enable “Less secure app access” or use an App Password if you use Gmail. It’s a clunky, early-2000s process, and we all grumble about it. But once it’s set up, it works reliably and ensures your patch is pristine.

The Sacred Art of the Commit Message

This is where most first-timers fail spectacularly. Your commit message is not a throwaway line. It is a technical document. Linus Torvalds himself gets openly hostile about bad commit messages, and he’s right.

The format is non-negotiable:

  1. A subject line under 50 characters, prefixed with the subsystem you’re touching. (drm/amdgpu:, net:, docs:).
  2. A blank line.
  3. A body that explains why you are doing what you’re doing, not what it does (the code shows that). Describe the problem you’re solving and your reasoning. If you’re fixing a bug, include the kernel log output or the commit that introduced it.
  4. A Signed-off-by: line at the end, added with git commit -s.

Here’s a terrible example vs. a good one:

Bad: “Fixed a bug.” (I will find you.)

Good:

net: ethernet: Fix use-after-free in nasty_driver_remove()

The nasty_driver_remove() function tears down the device but doesn't
null out the priv->dev pointer, leading to a potential use-after-free
if nasty_debugfs_read() is called after removal.

This was detected by KASAN on module unload. The crash log is below:

[   42.123456] BUG: KASAN: use-after-free in nasty_debugfs_read+0x42/0x60

Fix it by setting priv->dev = NULL after unregistering the device.

Signed-off-by: Your Name <your.name@example.com>

The good message tells the maintainer exactly what’s happening, why your fix is correct, and provides evidence. It’s a compelling argument, not a demand.

Finding the Right Maintainer: get_maintainer.pl

You don’t just blast your patch to the 5000+ people on the LKML. That’s a great way to get ignored. The kernel source tree includes a brilliant Perl script called scripts/get_maintainer.pl. Run it on your patch file, and it will tell you exactly who needs to see it—the maintainers and the mailing lists responsible for that subsystem.

git format-patch -1 HEAD --stdout > my_fix.patch
perl ./scripts/get_maintainer.pl my_fix.patch

This will output a list of emails. These are your primary targets. You copy them into the --to and --cc fields of git send-email. The LKML is usually CC’d so the world can see and review your work.

Sending the Patch and Handling Review

You’ve configured everything, written a masterpiece of a commit message, and found the right maintainers. Now, send it:

git send-email --to maintainer@kernel.org --cc lkml@vger.kernel.org HEAD^

And now… you wait. The response might be silence (resend after a week or two), a quick “Applied, thanks!”, or a review. Hope for the second, expect the third.

Review comments will come via email. They can be direct, blunt, and lack pleasantries. Do not take this personally. It’s not an attack on you; it’s a highly efficient focus on the code. You address every point, rework your patch, and resend it as a v2. The subject line changes to [PATCH v2].... You include a changelog below your commit message body but above the Signed-off-by:

v2:
- Fixed the spelling error pointed out by Jakub.
- Added missing NULL check as suggested by Miguel.

This process repeats until the patch is deemed perfect. It’s a grind. It’s iterative. It feels archaic. But it works. It forces a level of careful thought and broad peer review that a simple “Merge” button never could. You’re not just submitting code; you’re entering a conversation that’s been running for over three decades. Do your homework, and you’ll be welcomed.