First patch in the Linux kernel

Below is the very first patch that I recently landed in the Linux kernel:

diff --git a/drivers/staging/rtl8192e/rtllib_wx.c b/drivers/staging/rtl8192e/rtllib_wx.c
index aa26b2fd2774..2e486ccb6432 100644
--- a/drivers/staging/rtl8192e/rtllib_wx.c
+++ b/drivers/staging/rtl8192e/rtllib_wx.c
@@ -341,8 +341,6 @@ int rtllib_wx_set_encode(struct rtllib_device *ieee,
 		goto done;
 	}

-
-
 	sec.enabled = 1;
 	sec.flags |= SEC_ENABLED;

If you’re not familiar with the unified format, this patch removed two blank lines in a (random) C file. It took me an hour to write and test it as I double-checked every single command I ran to avoid making silly mistakes. I was kinda terrified but everything went well. Since then, I contributed some more patches to the staging subsystem. Patches fixing stylistic issues are welcomed in this subsystem and it is where newcomers should start.

Gaining confidence

I am proud of my first patch. Let’s be honest, this patch won’t make the kernel safer or anything like that, I only removed two blank lines and it’s just a staging driver (but distributions like Debian include it nonetheless). I wanted to write about it because I think it’s important to be reminded that, no matter our experience, we always have something to learn and we must learn to walk before we can run.

Very few people make outstanding contributions on a new project on Day 1. It takes time to get used to the contribution process, the different tools, the people you work with, etc. This simple patch introduced me to some of the Linux Kernel Mailing-Lists and how to use them. I learned about the staging subsystem and the whole concept of “subsystems”. Last but not least, I understood how patches were merged into the main Linux Kernel repository by following my commit from my local environment to Linus Torvalds’ tree:

1. I submitted a patch to the DriverDev-Devel mailing-list
2. after review, the patch landed in the staging-testing branch of Greg Kroah-Hartman’s tree (Greg KH is the maintainer of the staging subsystem)
3. after testing, the patch was merged into the staging-next branch
4. Greg KH prepared a (short-lived) tag for Linus and requested a git pull
5. Linus pulled the tag from Greg KH’s tree
6. First patch in the Linux Kernel! :)

Email-based git workflow

Submitting a first patch to the Linux Kernel is not super complicated but it is different because GitHub introduced a new approach to making Open Source contributions that became extremely popular. This platform enabled many developers, including myself, to work on Open Source projects using Pull/Merge Requests.

The Linux Kernel uses emails and mailing-lists to distribute patches and review code. sourcehut is a platform that leverages this process as well. I like that approach because all the metadata around the source code is open, public and sort of distributed. If GitHub goes down, a team cannot collaborate anymore because they cannot exchange patches or review code, until GitHub comes back. When GitHub removes a repository for some reasons, all the past code reviews and patches (Pull Requests) are lost.

Other Open Source projects like Firefox have [a different workflow]¹ too and it isn’t really easier than emails. That being said, most email clients are not compatible with the email-based git workflow by default, and that’s a huge problem. This workflow requires plaintext emails and, for the Linux Kernel as well as platforms like sourcehut, text should be wrapped at 72 columns and bottom posting should be used. The majority of email clients will be configured with HTML, no wrap (and/or no format=flowed support) and top posting by default, ugh.

Therefore, email clients that run in a terminal (like aerc) are kinda mandatory and I can see how user unfriendly that is. I spend most of my time working in a terminal, yet I do not use such clients. I started to use aerc lately, though. It’s the only way for me to be as efficient as I am with GitHub because aerc allows me to review, test and apply patches with ease. We’ll see how that goes on the long run.

Conclusion

As you can see here, anyone can contribute to the Linux Kernel. For me, it’s a personal achievement that makes me super happy. Then again, I do not think my first contribution has been very useful but it’s something. I’ll continue to land similar patches until I find some more involved problems to solve.

If you think this is stupid, well, not everyone agrees with you ;-)

willdurand> here is an example where I sent a series to cleanup a union and each patch fixes a single field in a struct: link. I realize it’s a lot of very small commits and I am not sure if that’s the right approach.

gregkh> willdurand: that approach was PERFECT! Exactly the correct thing to do, and the best example of “hey, go do it like that patch series” I have seen in a while. Nice job.

If you’d like to contribute too, Kernelnewbies has a lot of information to get started and everyone I interacted with has been very friendly.