5.16 Kernel Development Statistics | Hacker News Reader

5.16 Kernel Development Statistics

lwn.net

45 pointsgits122512 comments

This is fascinating but how accurate is this? Because Ping-Ke Shih is credited with the lines related to the rtw89 driver, but looking at their github repo[1] I see no such name in the contributors.

Did Ping-Ke just merge the driver and get credited for it? Or are they behind the lwfinger account?

Hard to tell but I'd like to buy them a beer or two for that driver, my laptop thanks them.

Also interesting to see a fellow Swede Johan Almbladh in the top 5. Apparently this guy is the founder of AnyFi that are trying to deploy Wifi towers in Indonesia. Looking at some of his commits he also works with the Loongson CPU architecture that came out of China many years ago. For a while Richard Stallman was using a laptop with one of those CPUs.

1. https://github.com/lwfinger/rtw89

Notably missing from the "Most active employer" list is the company that has the most Linux-based computers in the world.

It's definitely weird not to see Amazon there. Facebook is much higher than I would've expected though. But it's also just a snapshot, maybe the longer-term average is very different from that.

What company is that?

Amazon maybe?

I wonder how would active employers list look like sans drivers or rather sans vendor specific drivers.

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

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

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.

https://kernelnewbies.org/FAQ/WhereDoIBegin

The Linux Foundation also has projects in the Google Summer-of-Code (GSoC): https://wiki.linuxfoundation.org/gsoc/google-summer-code-202... In 2022 GSoC is expanding eligibility to non-students: https://opensource.googleblog.com/2021/11/expanding-google-s...

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

Reply on news.ycombinator.com