Linux Foundation Publishes Guide On How To Get Your Code In The Kernel

Development of the Linux kernel is a process that's a mystery to many outsiders. Someone who thinks he has just the right code to add to Linux periodically crashes into the hurdles that need to be leaped before the new code can get incorporated into the kernel.

The Linux Foundation is trying to do something about that. It's issued a guide on "How To Participate In The Linux Community," which outlines well-known standards and also unveils some of the little-known barriers.

The issue came up at the Linux Foundation Collaboration Summit in Austin last April. A panel of kernel developers was asked by Ed Reaves, technology platform manager at Nortel, how his team could move a quick restart patch it had developed into the Linux kernel. The patch had been submitted to kernel developers and had the potential of restarting a stalled Linux system in 20 seconds, moving Linux reliability from 99.999% to 99.9999%. But the patch wasn't progressing through the review process toward final approval by Linus Torvalds.

"How do you get a kernel patch released into the mainline?" he asked. The answer indicated that a little knowledge of how kernel developers work increased the odds of inclusion.

For example, Linux has a coding style guide, but not all patches arriving in the queue follow it. Kernel maintainers need to be able to read code quickly and easily. Contributed code that's been written in the style preferred inside a particular company sometimes runs afoul of the Linux style.

A kernel maintainer may ask a contributor to go back and resubmit the code in Linux kernel style and be told by the contributor, "If we make these changes, we'll have to go through our whole internal review process again," said Jonathan Corbet, executive editor of the Linux Weekly News. When contributors want code to be dealt with only in the form they've submitted, that's a nonstarter, warned Corbet.

Likewise, contributed code has to be matched up to the version of the kernel in which it may logically be included. That sometimes requires gearing it to the version of the kernel currently in Linus Torvald's open source code management system. Having prepared the contribution based on some other kernel version means the APIs on which the code depends may have changed. If the submitters don't know how to pull their code into alignment, then somebody else will have to do it, Corbet pointed out.

Submitting code is only part of the process. There's a give and take between submitter and reviewer that tends to revise the code several times, bringing it into alignment with other things going on in the kernel. If the submitter isn't prepared to participate in that process, his contribution may stall, Corbet said.

Still, "it's really not as hard as people sometimes think it is," said Corbet, a kernel developer himself. Each release of the kernel, which comes along every 60 to 90 days, has over 1,000 contributors to it, so the process can't be too difficult.

It helps to know that submitted code needs to be reviewed by an expert developer with knowledge of the area of the kernel to which it applies. It helps even more to have built a relationship with that expert before submitting code, Corbet said in an interview.

Corbet is the author of the online guide posted Aug. 13 on the foundation's Linux Developer Network site. The foundation is the organization that employs Torvalds and is backed by a broad set of dues-paying members, including IBM, Oracle, HP, Motorola, Intel, and other vendors with a stake in Linux's future.

"Kernel developers know that patches will be in the kernel for the long haul. The kernel developers will still be maintaining five years from now whatever gets merged today," Corbet said. The ease with which an addition works with other moving parts, without requiring changes to them, is a key standard to winning acceptance, he said.