5.16 Kernel Development Statistics

How would an enthusiast developer even begin to contribute code to the kernel? It seems quite a daunting task

Greg Kroah-Hartman has this video on writing and submitting your first kernel patch. https://www.youtube.com/watch?v=LLBrBBImJt4

I thought I remembered an article about this too but I couldn't find it.

edit: looks like sibling post by Decabytes might have it.

What company is that?

Like most open source, a good way is to use it and then find issues and fix them; aka scratch your own itches.

Here are the itches I have scratched and attempted to scratch in the Linux kernel:

I got my first commit into Linux many years ago by noticing the shortname mount option for the vfat filesystem was suboptimal and then sending a patch flipping the default to mixed.

Later when maintaining a simple core dump handler script, a bug reporter noticed that Linux was splitting the core dump handler string after filling in the parameters, instead of before, so I fixed that, with a few broken patches and a lot of help from other Linux devs.

Later I was using SSD+HDD mirrored with lvmraid (not mdadm RAID) and noticed that Linux doesn't allow TRIM/discard on lvmraid when one device supports TRIM but the other doesn't, I wrote a working patch for that but I used the completely wrong approach, so it was rightly rejected. I haven't managed to get back to that project and the HDD died in the meantime.

Later while helping users on the #debian-next IRC channel, after seeing a patch fixing the Bluetooth code by changing a magic number, I looked at the code and noticed a lot more magic numbers. Then I investigated what it would take to eliminate those magic numbers. I encountered a legal barrier and contacted the relevant Linux Foundation and Linux kernel folks, who assured me my approach would be fine. I haven't managed to get back to that project yet though.

While maintaining the Python implementation of iotop (the C implementation is better), I noticed there is no way to look up at runtime from userspace which syscalls a Linux kernel offers and what their names are etc. Haven't started on that yet.

When my monitor had an issue with the EDID going missing (turns out it was just a bent pin on the VGA cable I was using), I had the idea to create /sys/class/storage, which would let you back up all the non-volatile storage on your system that isn't a block device, like monitor EDIDs, BIOS variables, UEFI storage, pstore etc. Haven't started on that yet.

When I was forwarding my USB based webcam from my laptop to my desktop using the usbip tool and Linux kernel module, I noticed some ergonomic issues in the userspace side and started working on them. I haven't managed to get back to that project recently though.

My rejected and unfinished patches and TODO files are here in case anyone wants to pick these up:

https://github.com/pabs3/linux/branches/all

The kernelnewbies resources are often helpful, including the IRC channel:

https://kernelnewbies.org/

I think the best way though is a GSoC/Outreachy Linux kernel internship, that has full-time mentoring and often leads to job opportunities too.

https://github.com/fossjobs/fossjobs/wiki/resources

You just go and do it - it's just sending out an email. You don't need to introduce yourself, sign up anywhere, or do anything particularly fancy.

You do need to write code that works and will be accepted, and follow the expected protocol when submitting it. There's a lot of information on the process out there (some of it obsolete), but really it boils down to:

- git clone the kernel (latest release or latest RC usually works for this)

- Write and test the patch

- Make sure Git authorship info is correct and the commit is signed off (`git commit -s`)

- git format-patch to make the patch

- checkpatch.pl to check for style issues

- get_maintainer.pl to figure out who to send it to

- git send-email to send it properly