# WIP: How I Contributed To The Linux Kernel --- layout: post title: How I Contributed To The Linux Kernel date: 2026-04-16 08:37:22 -0400 categories: linux --- Yesterday, Linus Torvalds pulled a set of patches for the Linux kernel, that included some of my work. I thought it'd be helpful to share my experience, and tips for others about how I did so. Instead of sharing my story, I'll first explain my own, simpler "mini-guide" of how to get into kernel development (from a somewhat high level overview), and then I'll share my story. There is something transformative about contributing to the Linux kernel. It is one of, if not the oldest actively maintained codebases. Contributing to it means being a part of history, but also joining a group of tens of thousands of skilled developers. To be clear, this does not replace the official kernel documentation. You will need to read it. This is just an oversimplified view of how it works as a newbie, and some advice for how to get started. I feel like it's important for me to share this now before I forget what it is like being in the position that you may find yourself in as a newbie, reading this. First off, I'd suggest asking an AI how to get into kernel development, copy and paste its output into a document, printing it out, and NOT read it. Burn it, it's a great symbolic gesture. # Before You Begin ## What You Need You should be able to code. Shocking, I know. I recommend getting familiar with C. You don't need to know things like printf formatting offhand, but you should be able to read C code and understand what it is doing. Being a good programmer is one thing, but there are two things that will guide you on your journey: **patience** and **dedication**. - **Patience**: Contributing to the kernel is not a fast, easy process. You will be reading a lot of documentation, code, and spend a decent amount of time to make sure you do everything right. - **Dedication**: Know why you want to contribute to the kernel. If your goal is fame, it probably is not going to get you there. But if your goal is contributing to one of the most important codebases in the world, in good faith, in order to help others, you will be okay. Use the goal of accomplishment to help keep you moving. This also comes with a **good mindset** - you may (or rather, most likely will) experience some setbacks. *Stay confident!* Note: Contributing to the kernel and sending in your first patch is a marathon, not a race. Take your time and enjoy the process. ## Understanding the Scene The Linux kernel is not just any codebase. It is over 30 years old and is worked with on a daily basis by dozens, if not hundreds of people, all over the world, each day. This even includes companies: some manufacturers, like AMD and Intel actually hire people to develop and maintain drivers for their hardware. Linux is also used in many, very important areas. Not just desktop. Servers and companies take advantage of Linux. They rely on it being stable. Bugs can have real world consequences! ### The Repository, and Subsystems Because of how important the kernel is, and it's size and longevity, things do not run like the usual GitHub repository. The kernel *predates* GitHub. Actually, Git was made BECAUSE of Linux. The code, while mirrored on [Linus Torvalds' GitHub](https://github.com/torvalds/linux), is actually hosted on git.kernel.org. You are unable to open issues or pull requests on GitHub because that's not where the development happens, nor is it actually how patches are sent. Nobody actually pushes code directly to the kernel, except for Linus. This does sound a bit "dictatorship" at first, and even a bit scary, but rest assured, it is not that bad. What happens is, people develop their own patches in certain areas of the code. These areas tend to have their own Git repository or branch, and these are called **subsystems**. They each have their own set of maintainers and reviewers. The subsystem maintainers send the patches of their subsystem to Linus, who then usually accepts them (unless there is something really wrong). Example subsystems include the networking subsystem, the ext4 subsystem, the serial subsystem. There should be a list of them somewhere, but if you go to lore.kernel.org they are all there. So where do contributors send their patches? Everyone sends their patches to the subsystem (unless for some reason, you have a good reason to send it to Linus, but as a beginner you will not be in that situation). I don't want to speak for all subsystems, but most of them also have their patches sent.. by **email!**. Yeah, email! Next time you or someone else complain about Git or GitHub, just know that you are playing on easy mode. Anyways, patches get sent via email, then they get added to the subsystem, and then the subsystem sends them (also via email) to Linus. The beauty is that all the patches get sent together, not just yours, but also others (this prevents having a thousand emails of patches being sent around). Then they get pulled, but it's not always instant; it depends on where we are in the kernel release cycle. ### The Release Cycle I'm basically paraphrasing from the official docs, but essentially, there is really no "set date" for releases. Once a new version of the kernel released, a "merge window" opens, where subsystems send in their patches. This is where new features, drivers, and most changes occur. After two weeks, the merge window is closed, and from that point on, all patches sent are bug fixes. Every week, Linus releases a release candidate, and eventually when the kernel is "stable" enough, Linus makes a release, the merge window reopens, and the whole process starts again. So, most of the time, for new features or changes, your patches get sent to the "next" branches of the subsystem, which target this merge window. Fixes get their own branch - but again, I'm not going to speak for all subsystems. Basically, patches don't get pulled immediately, they all get pulled together via the subsystem, and depending on the kind of patch you are sending and when, it may get in sooner or later. # Getting Yourself Ready for Kernel Development As I said, kernel development is not a fast, easy process. You know how the release cycle works, but before you start working towards a patch, you need to set yourself up so you're comfortable with development. ## Email configuration For me, this was one of the most unique, yet cool parts of the process. However, it is long, and really deserves its own blog post. So bear with me here, but I promise it's important. If you want to skip my yapping, see the "final checklist" subsection. Since kernel development runs by email, you will need to prepare being able to work with sending email. However, you don't just send mail like any other email. There is a proper way to send emails, and therefore, patches. Here are the main rules of writing emails: - [Plain-text only!](https://useplaintext.email) No HTML. - Some email clients won't be able to read it, and may filter the entire message. - Similarly, do not submit attachments - Try to have a max line length of 80 characters. - My parents say 80 is a standard, which doesn't surprise me, but by keeping a max line length of 80 characters, it makes the email visually easier to read (and less mentally "stressful") - Respond inline, do not top post. - The last item will require some getting used to. Nowadays, most people respond with their writing at the top of the message. Email clients set this up for you by default. - But what you should do, is respond inline. That means you quote the part of the email that you are talking about, and then respond to it below. This makes it easy to follow conversations. There are also rules for [formatting patches](https://docs.kernel.org/process/submitting-patches.html) - this is a bit difficult at first. There is a page for [mailing list etiquette](https://subspace.kernel.org/etiquette.html), which you should read - [this post](https://people.kernel.org/tglx/notes-about-netiquette) is also good too. Keeping all this in mind, what you *could* do is configure your [email client](https://docs.kernel.org/process/email-clients.html) for these rules, but just trust me when I say, you want to use [git send-email](https://git-send-email.io), and with `git format-patch` it's really not a big deal. What I did was start using [aerc](https://aerc-mail.org). It's a TUI mail client that has good integration with git and email. If you want to use another tool, go for it. As long as you can make sure that you are composing in plain text by default, responding inline, and have some kind of indicator to make sure you don't boil over 80 characters per line, it will work. With aerc, I can compose using any terminal text editor, so I use [helix](https://helix-editor.com). I've really enjoyed using it, and I recommend it. Of course, there is a learning curve to aerc, and the configuration takes time. I started by just having it directly pull my inbox, but it takes time to load all the messages, causing it to time out sometimes. The solution is using mbsync and notmuch to download my mail locally instead of having aerc request them every time I wanted to use it. There are a ton of other benefits to this that I won't go into, but trust me, it's worth it. I jumped through some hoops with Outlook, and then [Forward Email](https://forwardemail.net/), which is what does the sending/forwarding for my @ubuntu.com email alias. This is where patience comes in handy. A lot of the configuration, in my experience, was trial and error, because of Microsoft's strict rules for sending messages. This meant having to find a Cyrus SASL XOAuth2 implementation (which I had to build manually on my system because a prebuilt package was not available), and then having to use a script to get the permission tokens that basically acts as if the client is Thunderbird trying to authenticate with Outlook, and then you have to sign the token at rest while also dancing with Microsoft's account authentication. I forgot how most of it works at this point, and I could probably make an entire blog post about my journey with this. But Simon Dobson's [blog post](https://simondobson.org/2024/02/03/getting-email/) on how he got Office 365 working with mbsync helped out. If anyone needs help configuring their mail client with Outlook, let me know. Of course, that was my experience, you may not have an Outlook email or you may not use aerc. But once it's done, consider setting up an automatic systemd timer to pull your email, and voila, you are set. Each person's experience will be different, so I cannot speak in a "general way" to give advice, but can only speak to my experience. ### Managing your email Sorry, not quite done yet. You know that feeling when you have a new email, and you try to make it so you are on top of every message, and leave NOTHING unread? This is a great opportunity to do so. Get in the habit of reading your emails regularly and not "holding things off for later". It's a great feeling and you will want to be up to date with what is going on in the kernel community! I also recommend setting up your email provider to **start tagging and automatically organize your emails into folders**. This not only helps with the prior goal of not leaving unread emails sit forever, but makes it so if you are a part of multiple projects, the totally different emails won't be sitting next to each other. My inbox folder has 5 years of junk and it takes aerc a few seconds to load it from notmuch. Now I have folders for Debian-related, Home Assistant-related, Linux Kernel-related, Ubuntu-related, and Wii U Smart Home Project-related. When I see a list of emails, I know that it will be in one area of focus, not ten different ones. ### Final Checklist Phew! Sorry that I had to weave into my own experience, but email configuration is important. It really deserves another blog post of its own. Make sure that: - You have setup and configured a mail client that will respond in plain text, proper email formatting - You are using mbsync/isync and notmuch to pull your emails - You configured your mail client to get the mails from notmuch - You set your email service to automatically tag and categorize your emails - You are comfortable with your mail client - but if you aren't yet, you'll get there with practice :) **Yay!** You have setup your email management for use with kernel development. You should be ***VERY*** proud. You're a cool kid now, using email the way it was probably originally intended to be used - by writing in old-school plain text, using the terminal for mail instead of those big, heavy GUI clients, and having an organized system of managing your email. Give yourself a pat on the back, and back up those configurations, this way it won't be as painful when you switch devices. And don't stress about all the formatting and rules: you will get used to them. ## Reading documentation.. although its spread out # Getting Acquainted With The Kernel ## Building it, having your config file ## Checking for errors ## Some tracing, understanding of the codebase # Actually Starting Development ## Looking for work: ideas of things to do # Submitting Your Patch # My Story