I Want to Contribute to the Linux Kernel

I want to contribute to the Linux kernel

Start with these: Kernel Bugs involving typo.
(Search everyday until you find something promising).
Search that bug database with keywords like "comment", "typo", "documentation", "minor bug", etc.
Also, search under the category Documentation here.

Learn the process first. Then, attempt to contribute something significant.

How does one submit a potential patch to the Linux kernel?

Before anything else:
concentrating about the performance bug report, and getting it right (with repeatable benchmarks) will at least help you to get people to bother with the problem. Also submit the patch after testing it, but beware that your great patch might use the wrong approach, and that they might write a better one. Or that simply it may be great, but might need fixes to get accepted, that even happens with uber-guys. And don't think to email somebody privately, but refer to LKML or to the appropriate subsystem ML.

I'd suggest you to read through all other answers, and all applicable material, before contacting kernel developers; and read the bibliography of SubmittingPatches as well.
They might be harsh if you do it wrong. The kernelnewbies IRC chat is a good place for you to start, because they are for sure welcoming, even if sometimes the environment can be too newbie-like (not sure, I've not been there so much).

It may be that I'm being overly optimistic in thinking someone the kernel world's never heard of can contribute, but I'd be interested to find out.

It's not overly optimistic; not in itself at least. Abstracting from you (since I don't know your skills), what is more unlikely is that your patch will be accepted without modifications, or that it's written according to the right skills. But actually, if your patch is addressed to a smaller community, it may be much easier.

From somebody with some experience (i.e. me), before considering the patch submission, describe the problem and why it affects other applications. Considerations like "this improves our performance", especially if you qualify (vaguely) as a vendor, won't have appeal on kernel developers.

Especially, omit such statements:

rendering our current implementation workable, but less than optimal.

because this will buy you a "fix your code" recommendation immediately by most readers.

If performance of an existing application (not written by you) is impacted, that's different. For instance, once Linus promptly paid attention to fixing in the kernel performance for screwed up code, because that code was part of make, even if he was proud of the code he had written and of the fact that he didn't need to do that exact fix. I.e., you need an application which everybody cares about, or a solution without disadvantages.
So, stuff like:

behavior from an another (very commonly used) application

is good, as long as your usage of that application is not deemed unreasonable.

Finally, if you refer to source code, they'll likely ask to see the interested section - think to license issues with your code, if they exist, and solve any of them beforehand if you want to answer them quickly.

Btw, this is a partial account of my experience there:
https://www.ohloh.net/accounts/Blaisorblade

If you want, you can contact me to help you directly with a proposed mail, and CC me on the discussion. I'm quite busy, but I might find some more time :-).

Contributing to a Linux distribution

Unless you have a specific desire to learn the ins and outs of various packaging formats you would probably be better off contributing directly upstream to applications/libraries that you find interesting. While individual distributions often have a few management applications that are unique(ish) to them most core applications and libraries are shared between them.

As you have expressed an interest in guts it would make sense to stick to one of the main community distros (Fedora and Ubuntu/Debian) as the rest tend to be variations on a base distro. The other option is to choose a source based distribution which have a number of advantages to developers although you may find yourself spending a bit of time keeping your machine trim.

As I'm a developer I personally use Gentoo which gives me a number of things:

• Rolling release: New versions of applications are generally available soon after release
• Stable/Unstable mix: I can run stable core with bleeding edge on upstream packages I care about
• Development ready: Any installed package is by default a "dev" package, the distinction between buildtime/runtime dependencies is blurred
• Packaging is easy: If it's a simple as "configure/make/make install" writing and ebuild is very easy.
• Contribution is easy: Contributing new ebuilds is fairly painless, from there you can get as involved as you like

Of course there are downsides, not least of all your machine spends a considerable amount of time building things and if your run a large selection of "unstable" packages you may find you occasionally need to fix-up your machine. However I find these disadvantages minor compared to giving me an up to date platform with which to contribute to upstream from.

Is it reasonable to try and modify the Linux kernel?

Go to LKLM and check the archives if someone else is already working on something similar. If not, announce there what you plan to do and ask about the easiest way to accomplish it (kernel module, etc.). Create your own git repository to make the changes and allow others who are interested to pull from your repo. If your work turns out to be successfull, ask a maintainer to pull your changes and add them to the mainline.

It's certainly not unreasonable to do, but only you will know if it's worth your time working on those deep modifications.

where to start linux kernel programming?

I'm not a kernel person at all but I work with a lot of people who are very much into the kernel. They all recommend Linux Kernel Development by Robert Love as a good book on the subject. I've bought the book myself and plan to, in my copious free time, go through it.

The Kernel Mentors mailing list related resources at http://kernelnewbies.org/KernelMentors is also a good place to look at.

Learning Kernel Programming

Try to get hold of Robert Love's book on Linux Kernel Programming. Its very concise and easy to follow.

After that or along with that, you may want to take a look at "Understanding the Linux kernel".But I wouldn't recommend it during the early stages.

Also, look at the Linux kernel programming guide. Since a lot can be learnt from programing kernel modules, that guide will help you. And yes, for a lot of information, consult the 'documentation' sub-directory of the Kernel sources tarball.

---

Related Topics