This may or may not be off-topic. If it is, leave a comment and I'll take it down.

I am trying to become a kernel developer myself, and reading some of the mailing lists, I can only help but wonder where Linux kernel developers find places for improvement in the Linux kernel. Looking at the kernel's bug tracker, there actually aren't that many kernel bugs, and a lot of patches are related to optimizing or otherwise improving the kernel's internals. So that leads me to this question, of how these developers find out what these places for improvement are in the Linux kernel.

Again, if this is off topic, leave a comment, and I will take it down.


4 Answers 4


In addition to the other answers (which may hint that this question may be off-topic or the answers should be transformed in wiki-answer).

  • There are a lot of distributions, many with good kernel developers, but in any case most with knowledgeable person which may triage and communicate to the right people about bugs. Do not think just generalist distributions, there are specialized ones, e.g. openwrt for routes with may use kernel differently, or also all virtualization images

  • many developers are paid by some companies. For distributions, the developers may check further on nuisances (which may hint a bug). For hardware manufacturers (devices and architectures) they may put extra stress tests. And sometime just discussing between developers you may get a bug (different parts may have different assumptions).

  • Stack: you have many standard libraries and programs which uses directly the kernel systemcall. They probably have extensive tests.

  • There are various test for kernels, and many of them are performed regularly on development (and release) of kernels.

  • Development and debugging: changing code (or just viewing it), may reveal more important bugs in unrelated parts of kernel. Note: also just by looking the code (maybe because you want to improve one part, so you must understand how other parts uses your code, etc.)

Do not under valuate how many different machines and uses there are, so there are always new bugs showing up. Note: by being a developer, you may see problems before they become bugs, but also you can probably assess if it was an already fixed bug, or a new one.

As a note: once I submitter a bug report, and two bugs were corrected. One by the system maintainer (regression), but the second one by Linus Torvalds (on an higher level) because the first bugs hinted a weak general code.

Check: https://kernelnewbies.org/ and maybe also some subsystem specific mailing lists, and ask. There will be people willing to help new developers.

  • A lot of the sponsored developers mostly work on adding and updating the drivers for their sponsors' latest products. All kinds of new hardware, new virtualisation, new filesystems, new communication standards. And then fixing the bugs in all that until it's sufficiently stable.
    – OrangeDog
    Nov 13, 2023 at 14:19

There are (at least) three ways to find bugs:

  • Someone using the program may notice it behaving in an undesired way. This could be a feature they want, or a defect (i.e., bug).
  • While looking at the code directly, a defect could be spotted either as a difference between advertised behavior (from a comment or documentation or from other sections of the same code) for that code and what it actually does, or possibly an accidental misuse, such as an array subscript out of bounds. This could be done by mechanized means (such as compiler checks) or by human eye.
  • External programs (frequently called fuzzers) can attack the code in random ways and attempt to make it misbehave by random chance.

Likely you don't see many kernel bugs because they are fixed quickly, when found, not because there are not many.

A feature request is distinguished from a bug in that it usually involves adding new code for new behaviors, where bugs are mistakes in existing code. The optimizations could be either bug fixes or new features.

As a new kernel developer, probably optimizations are very difficult.

Your best bet (as already suggested) might be to find a device that is not currently supported or not well supported and try writing a driver for it.

But just reading through existing kernel code without finding a need to make changes may in itself be a good way to get into kernel development. Following discussions on optimization and understanding how new optimizations work would be equally valuable.

  • Yes! :) About "trying to improve things one doesn't understand", I am reminded of some adage "when you see a fence out in the middle of nowhere, and you don't know why it's there, don't tear it down". :) Nov 13, 2023 at 0:16
  • Really liked this one. Thanks!
    – oli2
    Nov 14, 2023 at 3:03

bugzilla.kernel.org and LKML are an infinite source of issues and things to fix or improve.

And then there are simply very smart people. They read the code, realize it can be done differently in a far more efficient manner, thus we have performance improvements.


This is from my point of view as a user space developer for Linux, rather than an active Kernel developer, but in searching for how to achieve something you find there is a patch set which has yet to be incorporated into the mainline Kernel.

E.g. A full task-isolation mode for the kernel looks useful for a specific use case but as far as I can tell it is not yet in the mainline Kernel as searching for CONFIG_TASK_ISOLATION in https://github.com/torvalds/linux finds no hits.

Trying to get such a patch set incorporated into the mainline Kernel could server as the starting point for a Kernel developer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .