Zack's Kernel News

Zack's Kernel News

Article from Issue 90/2008

 

Speedier Driver Merges

Recently, Linus Torvalds reduced the hurdles required to get code into the kernel. When Linux first entered the scene, one of Linus's main priorities was to encourage contributions. To that end, he made a point of being responsive to any patches that came across the group, accepting many and even publishing hand-crafted statistics about the patches received. As contributions increased in the late 1990s, his responsiveness dwindled, and he became more likely to drop patches on the floor if he didn't like them. Linus also began insisting that the design and algorithms be beautiful and that different parts of the kernel communicated in the ways natural to them.

As Linus adopted the "stable" and "development" kernel trees, he maintained his insistence on good taste, but he became even more strict during the "stable" cycle. With the overt structuring of kernel code submission into a hierarchy of maintainers and "lieutenants," Linus began to create a culture of adherence to his coding preferences – wherein other people who understood his tastes could act as gatekeepers – in addition to doing the technical work of coding and reviewing code for bugs. With his use of BitKeeper and the git, Linus's culture of "coding taste" could be further distributed to particular projects working in isolation, in which the individual contributors could review each other's work without it first having to be part of the main kernel tree.

During the 2.6 tree, Linus abandoned the somewhat uncomfortable swings between stable and development trees. He then reinstituted a set of micro-forks for stable development, in which the main 2.6 tree never left the development phase and each release spawned a new stable fork, just for bug fixes. The decision to abandon the original stable/development cycles marked a time of rethinking a variety of problems. One of the main justifications for the change was that the Linux distros always layered their own specialized patches on top of the official kernel releases. This made at least some of the efforts at stability somewhat moot, because the distributions often would use cutting-edge patches that could not have been as thoroughly tested and reviewed as the official stable kernel.

[...]

Use Express-Checkout link below to read the full article (PDF).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News