Contributing code to the Linux kernel probably seems about as easy as, say, reading the entire Buddhist canon in its original Pali. Now there's a how-to guide, written in plain English, about how exactly to go about being a "kernel guy."

Written by Jon Corbet (himself a kernel contributor) and entitled "How to Participate in the Linux Community", the guide's been offered under the aegis of the Linux Foundation's Linux Developer Network. It's not a programming guide, since that subject is covered in far greater detail by any number of other books and tutorials. Instead, it's about the etiquette and protocol of kernel submissions -- something that's often just as hard, if not harder, than the code itself.

The guide steps a prospective kernel developer/contributor through the process of not just submitting a prospective kernel change but making sure that all the ducks are in a row long before. There's a lot of emphasis on figuring out exactly what problem you are trying to solve before you write a single line of code, the better to avoid wasted effort that might only have to be scrapped and restarted later on.

There's been a lot of talk about how tough it is to get changes accepted into the kernel mainline -- e.g., the (to put it mildly) rough-and-tumble attitude that folks take on the kernel mailing list. "Don't waste our time" and "This won't work the way you want it to" are two common criticismS levied against potential contributors. One example, quoted from the guide:

... some years ago, developers working with Linux audio sought a way to run applications without dropouts or other artifacts caused by excessive latency in the system. The solution they arrived at was a kernel module intended to hook into the Linux Security Module (LSM) framework; this module could be configured to give specific applications access to the realtime scheduler. This module was implemented and sent to the linux-kernel mailing list, where it immediately ran into problems.

To the audio developers, this security module was sufficient to solve their immediate problem. To the wider kernel community, though, it was seen as a misuse of the LSM framework (which is not intended to confer privileges onto processes which they would not otherwise have) and a risk to system stability. Their preferred solutions involved realtime scheduling access via the rlimit mechanism for the short term, and ongoing latency reduction work in the long term.

The audio community, however, could not see past the particular solution they had implemented; they were unwilling to accept alternatives. The resulting disagreement left those developers feeling disillusioned with the entire kernel development process ...

The most important thing I'm gleaning from this anecdote is how the kernel folks and the audio developers were seeing the whole thing from two entirely different perspectives. The audio folks were worried about their corner of the world; the kernel staff had to worry about everything. It's not easy for people focused on one problem alone to keep that in mind, but that's the point of documentation like this: to give a broader perspective on a process that's normally only seen through one keyhole at a time.