last updated: Fri Aug 19 13:00 BST

Linux Patches: Reward Cooperation, Punish Selfishness

In "ARM is a promising platform that needs to learn from the PC", a general solution is proposed to the ongoing problem caused by nothing more than the ARM architecture being by far and above the most ubiquitous silicon-based computing engine on the planet. The solution is, at its core, very simple: penalise selfishness, and reward cooperation. This is the basic fundamental principle behind Free Software, and the Linux Kernel is rapidly moving towards a dumping-ground for selfish SoC manufacturers, selfish ODMs and pathologically selfish Corporations in general to expect the Free Software Community to clean up their mess.

This fundamental principle - to reward cooperation (by prioritising patches where collaboration is evident) and to penalise selfishness (by rejecting or de-prioritising patches which are for one device, one CPU, for one manufacturer and conform to no common standards) - has accidentally been in effect since the very first Linux Kernel, across virtually the entire x86 platform. but only by sheer luck.

For example: the PC "BIOS" is responsible for normalising all PCs, Laptops, Servers and Embedded x86 systems. Thus, behind the "BIOS" is enforced and reluctant cooperation, with a history of lawsuits and reverse-engineering behind the second and subsequent compatible BIOSes. The Northbridge-Southbridge architecture is responsible for normalising system architectures. The use of the ISA bus, which spawned the IDE Drive as well as, decades later, the PCI bus range, meant that a vast range of peripherals are covered. USB is the same. VGA is, again, the same. At every level of the x86 architecture, there is evidence of cooperation through standards (or forced through de-facto standards), and the end result is massively less work required to be carried out to maintain the x86 Linux Kernel.

This is the "Lesson of the PC" that the ARM community has not learned.

Therefore, the proposed rule that is advocated for Linus Torvalds to adopt towards patches is this:

Within this profoundly simple proposed rule, there is a great deal of flexibility, which it may help to illustrate with a FAQ. It is assumed in each and every case that existing code-quality rules apply, and that the patch follows and meets, without fail, every single other well-established rule which is normally applied to Linux Kernel Patches.

Overall, it can be seen that many of these examples appear to be common sense. And, for every single one of the above to which there is an answer "no", close examination shows that if the CPU was an x86 architecture, in may cases there would be absolutely no problem. It is only in the context of massive diversity - devoid of common standards and cooperation of any kind at quite literally every single level, from the CPU's core architecture, to its peripherals right the way to the actual PCB - that the maintenance of ARM-related Linux Kernel Source Code becomes a complete nightmare.

Or, more specifically, the Linux Kernel Source Code presently and accurately reflects the state of play: total selfishness of all Corporations involved in making money out of the ARM architecture, at the expense of the Free Software Community.

The proposed rule therefore puts collaboration and cooperation directly at the heart of the Linux Kernel Free Software Development, where it belongs.

Comments and FAQ examples to: