Who writes Linux? (And how you can too!)

David M Williams
Monday, 25 August 2008 22:06

Opinion and Analysis

As you’ll have figured out a patch doesn’t just go straight into the kernel upon being put forth as a must-have bug fix or new feature.  Instead there is a route that must be followed.

First, patches are posted to relevant mailing list and the vigilant developers on those lists with reply with any comments they can consider. The bulk of major problems should be identified by this process.

Next, the review is cast further afield. As Linux is such a vast piece of software the kernel is conceptually divided into various subsystems – networking, memory management, video, and so on. Each subsystems has its own designated maintainer and this person is the gatekeeper for their portion of the kernel.

So, a designated subsystem maintainer will accept the patch as part of their area of responsibility. This acceptance does not necessarily indicate a patch that has come this far will ultimately be successful in seeing the light of day. Instead it means that the submitted code has no glaringly obvious oversights.

The patch now shows in the subsystem maintainer’s source code tree along with the other items they are working on. The new code is now combined with other work being carried out on support and submissions from others. Any problems resulting from the integration of the patch with other in-progress code are revealed and this leads to more extensive scrutiny.

Here comes Torvalds: eventually your patch will have successfully ventured through these legions of guardians and their varying source code trees. At this time Linus takes the work which has been performed and merges it into the so-called mainline repository, the veritable heart of Linux.

Depending on the quality of your code, comments will come fast or slow here, identifying problems to be resolved, suggestions for improvements, even discussion on whether the enhancements implemented by your patch are of sufficient interest and if they are consistent with everything else planned for the kernel and its evolution.

It is vitally important that the patch developer – you, the reader, in our sample scenario – is responsive during this period. The developer must fix the bugs which are revealed and consider the suggestions or other comments put forth.

The Linux team finally reach the point where they have a stable new kernel ripe for release and public consumption. This will be downloaded by keen enthusiasts, it will be bundled as an update package for most Linux distributions, and it may be included on disc for the next major release of any distro. You now have a stable version and your program code has withstood the close gaze of many hard working people.

Yet, by the same token, it’s also about to get hammered as tens of thousands of people begin downloaded the new kernel release within moments of it being available. There’s little chance to rest: with so many “testers” using your code in real-world situations it’s inevitable more bugs will be found. Fortunately by being part of the official kernel help can be readily found from your peers.

And that is how Linux works: Lots of individuals, all pulling together, and all with ultimately the same goal, desiring to further the cause and quality of free software.