How to move beyond basic style fixes when contributing to the Linux kernel?

Hi everyone,

I'm just getting started contributing patches to the Linux kernel, mostly focused on fixing coding style issues reported by checkpatch.pl. It's been a great way to learn the structure of the codebase and the submission process.

My question is:
What types of patches or fixes should I aim for next to grow as a contributor and not get stuck doing only the most basic cleanups?

I'm interested in gradually moving toward more meaningful contributions, but I’m not yet sure which areas are appropriate for someone still learning. Any advice or suggestions (like subsystems that are beginner-friendly, simple refactoring tasks, or places that need more attention) would be really appreciated.

Thanks in advance!

Make fixes to the areas that you're sufficiently interested in to spend time learning and understanding. You need to understand the challenges/tradeoffs that existing developers have encountered/made to be able to accurately assess whether something might actually need/be an improvement.

Nobody here can tell you what you're interested in.


If you want specific advice from kernel experts, go to the places where kernel experts provide advice.
//www.kernel.org/category/faq.html#how-do-i-get-involved-with-linux-kernel-development
//kernelnewbies.org/FAQ/WhereDoIBegin

There really aren't any beginner friendly subsystems. Read the LKML archives for several subsystems and see if you like anything. If you find something, then you start following that mailing list and start studying that subsytem code. Look at bugzilla and see if you can find something simple to fix. (Not all subsystems use bugzilla)

Learn to use syzkaller. That's important. Work on those issues. Even if you can't fix an issue, it will expose you to the subsystem.

Look for a simple patch where you understand what the issue was, ideally replicate the issue on that kernel version. Then implement the patch code and understand everything about what was done and why. Do this repeteadly, if you find enough such patches.

I don't want to discourage you, but it's tough as a hobbyist. There is a reason why almost all contributors work for companies where they write kernel patches for a living. They are exposed to real world issues, they have to make clearly defined enhancements, and usually they work in teams where they can get mentored in the beginning.

Another option is to write a driver. It doesn't expose you to a subsystem, but at least you go beyond checkpatch.pl and you become the maintainer for that driver.

You could look at the TODO in all those directories in GKH's tree. (maybe you are already aware of this)

https://web.git.kernel.org/pub/scm/l...rivers/staging

When you read the mailing lists, you see people who contribute regularly somewhat complex patches, and they still get corrected by the maintainers. It's a deep well and it takes time and perseverance. As a hobbyist, success is not guaranteed.

This question pops up every few months including on Reddit, so web research will find some ideas.

A similar question, which is the goal in this post, is to learn more about how the whole kernel works.

My suggestion, which might be relevant to a wide audience, those who run virtualbox, is: to config the minimal options for a Linux distro to run with the virtualbox devices, like hardware where everybody has the exact same!

Anyway, best wishes for fulfilling success in whatever you do.

BTW, I asked AI about this .config, and it seemed to know, but I'd bet anything it's wrong!

If I may. Sometimes style clean ups are as big a help as "new ideas". They make it easier for others to do what they can come up with. We can't always be the big idea person. But we can have an equal share in progression one way or another. Just not as glamorous.

Think of it like the janitorial staff at a hospital. Place shuts down instantly without those folks. The dr's & nurses are the only ones anyone seem to care about.