Wanna Be A Kernel Guy? Here's How - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Government // Enterprise Architecture
Commentary
8/13/2008
11:49 AM
Serdar Yegulalp
Serdar Yegulalp
Commentary
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Wanna Be A Kernel Guy? Here's How

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."

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Slideshows
Data Science: How the Pandemic Has Affected 10 Popular Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/9/2020
Commentary
The Growing Security Priority for DevOps and Cloud Migration
Joao-Pierre S. Ruth, Senior Writer,  9/3/2020
Commentary
Dark Side of AI: How to Make Artificial Intelligence Trustworthy
Guest Commentary, Guest Commentary,  9/15/2020
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
IT Automation Transforms Network Management
In this special report we will examine the layers of automation and orchestration in IT operations, and how they can provide high availability and greater scale for modern applications and business demands.
Slideshows
Flash Poll